[  285.467448] ------------[ cut here ]------------
[  285.467451] WARNING: ./arch/x86/kvm/mmu.h:227 at paging64_walk_addr_generic+0x7fc/0xa00 [kvm], CPU#20: CPU 11/KVM/9733
....

I am hitting this WARN_ON_ONCE that was committed here:

https://lkml.org/lkml/2025/9/19/1479

I believe it's because of the shadow stack (PFERR_SS_MASK) that my newer EPYC processor supports. We did not see it on another server that did not have shadow stack support.

Only started seeing this on the QEMU 11 upgrade. Coincidentally, CET virtualization was added with this release:

https://www.phoronix.com/news/QEMU-11.0-Released

Which corresponds to that warning and flag.

CET is an umbrella term coined by Intel for Shadow Stack and Indirect Branch Tracking. My processor only supports Shadow Stack and not IBT since it's AMD. To be clear, that particular code path is agnostic to whether its an Intel or AMD processor.

@fw1976 I should probably continue this discussion in the thread you started, but there are still some issues with Qemu11.

Boot loops and startup failures are still occurring on virtual machines with HVCI and RDS roles added.

*This also happens with Hyper-V roles, but since nested virtual environments aren’t meant for production use, I understand that reconfiguration is necessary in this case…

However, we should not cause issues with HVCI or RDS, which are not experimental features. It would be counterproductive for the addition of MBEC/GMET used by HVCI to cause problems in environments where HVCI is enabled.

In addition, there are other issues, such as those listed below. These issues remain unresolved.

Apr 23 10:24:37 pve1 kernel: ------------[ cut here ]------------
Apr 23 10:24:37 pve1 kernel: WARNING: arch/x86/kvm/vmx/nested.c:4462 at vmx_check_nested_events+0x910/0x920...

Known issues:
None at the time of publishing.

???

Never mind, apparently, even with Fiona's patch, shadow stacks are still exposed to the Windows guest when VBS is enabled. This was confirmed in the guests by verifying that "Kernel-mode Hardware-enforced Stack Protection" was reported in the guest OS, even though "-cet-ss" was present on the QEMU command line for that guest.

@Upstairs_Cycle384 Not sure why Windows still detects it, maybe querying the CPUID leaf directly still works or something. Regarding the other question, there is a custom CPU model editor coming with the next Proxmox VE 9.2 point release. There, you can define CPU models with arbitrary flags.

Has anyone observed any performance impact (especially CPU overhead or VM exits) after disabling CET flags on newer CPUs?

When I enabled HVCI on a virtual machine running Windows Server 2025, the CPU benchmark results weren’t particularly bad, but I encountered issues such as being unable to use the Start menu, and the system would immediately hit 100% CPU usage and hang after just a few operations.

* We have also confirmed that if the 100% usage persists, a BSOD with error code 0x00000133 (DPC_WATCHDOG_VIOLATION) will occur. This issue is likely to reoccur immediately if you continue to interact with the system while it is frozen. I don't want to look at this problem anymore, so I'm not going to analyze the memory dump.

Although hardware acceleration was added to HVCI, the user experience was so terrible that we ultimately decided to stop using HVCI entirely.

* Winsat formal -restart isn't bad for checking RAM and CPU speeds, even if it doesn't test the GPU.
With the upgrade to Kernel 7, hardware acceleration has been enabled, resulting in improved performance figures. However, the actual user experience is extremely unpleasant.

It wasn't that bad before QEMU 11 came out, so I think the situation has worsened due to the combination with the kernel.

* I think it actually ran much more smoothly when I used the combination of Qemu 10 and Kernel 7.0.0.3 with `migratable=off` enabled.

PS C:\Users\admin> (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).AvailableSecurityProperties
1
2
3
4
5
PS C:\Users\admin>

PS C:\Users\admin> (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).AvailableSecurityProperties
1
2
3
4
5
7 <- MBEC/GMET is available.
PS...

cpu: max,hidden=1,flags=+pdpe1gb
args: -cpu max,migratable=off

Do you pass any hugepage kernel parameters on your Proxmox host?

I've only set `default_hugepagesz=1G`, but whether I specify `hugepages: 1024` or not, the CPU usage remains at 100%.
The performance drop is so noticeable that even mouse movements feel sluggish—don’t you experience the same thing?

However, since we haven’t verified this with AMD, we don’t know if this applies only to Intel.

*By the way, we’re talking about delays here, but you’re not just asking about parameters out of the blue, are you?
If you're referring to “flags=+pdpe1gb,” that's just a remnant of a previous configuration.

Thank you. After applying all the flags @driley reported in the previous thread using augs, the issue where the system would hang with 100% CPU usage no longer occurs, but this also renders the Qemu 11 update intended to avoid using augs pointless.

Furthermore, although CPU usage no longer reached 100%, the Start menu stopped responding (Shellexperienshost.exe stopped responding to input), and since disabling HCVI restored responsiveness, the system remained unusable.

*This appears to be caused by repeated BSODs. While the system is now displaying properly after being repaired using the DISM command, it remains slow.

Ultimately, the conclusion remains that Intel products lack stability—since the use of augs is necessary and official settings for making this work correctly on Intel hardware have not been released (making it impossible to use without augs)—and they remain usable only on a limited number of products.

args: -cpu host,+hv-evmcs,+hv-ipi,+hv-relaxed,+hv-runtime,hv-spinlocks=0x1fff,+hv-stimer,+hv-synic,+hv-time,+hv-tlbflush,+hv-tlbflush-ext,+hv-vapic,+hv-vpindex,+hv-xmm-input,+kvm_pv_eoi,+kvm_pv_unhalt,level=30,+vmx-mbec,-hv-stimer-direct,-hv-tlbflush-direct,-x2apic,-cet-ibt,-cet-ss
cpu: host

*It’s unrealistic to expect people to understand all of this and enter data correctly. Even though we’re implementing this without fully understanding it, there has been some improvement compared to before. It’s also a case of putting the cart before the horse, where we intended to avoid using `augs` but ended up having no choice but to use it.

If this is the official stance, it’s unfortunate that it isn’t working properly.

You can achieve the same result with the following settings. I don't think this is possible with CPU settings alone.
This delay is similar to that described in the previous settings. Compared to when HVCI is disabled, it takes a little longer for the Start menu to appear.

*Well, I have no idea why it's working, though.

args: -cpu max,level=30,-cet-ibt,-cet-ss,migratable=off
cpu: max

I think it shows up only with Qemu 11.0

Could you verify this? It would be interesting to know whether it occurs with either pve-qemu-kvm=10.2.1-2 and pve-qemu-kvm=10.1.2-7 too. You can downgrade the package, and then start a VM for testing (and then upgrade it again before starting other VMs if you would like to avoid them also using the older version).