Subject: Native CPUID on AMD KVM causes Windows 11 kernel spin despite matching topology

[qiusheng-aim]

Hello,I tested Native CPUID with meowdiocre/devirtz-kernel-style AMD SVM changes on an Arch Linux KVM/VFIO host.Host:• AMD Ryzen 7 9800X3D, 8 cores / 16 threads• Arch Linux, Linux 7.1.3 Zen• Windows 11 guest, Q35 + OVMF, RTX 5080 VFIO passthrough• 24 GB HugePages, SATA disk, e1000e NICThe normal CPUID-intercept configuration is stable:• Windows boots to the physical RTX 5080 display.• host-passthrough, hypervisor=off, kvm hidden, aes=off• Guest topology: 6 cores / 12 threads, with 2 cores / 4 threads reserved for the host.For the Native CPUID test, I:• Cleared the AMD SVM INTERCEPT_CPUID.• Changed the guest to 8 cores / 16 threads.• Removed aes=off.• Pinned every guest vCPU to the host thread with the matching physical x2APIC ID:
0->0, 1->8, 2->1, 3->9, ... 14->7, 15->15.• Verified raw CPUID topology:◦ Leaf 0xB: 2 threads per core, 16 logical CPUs per package.◦ x2APIC IDs matched the QEMU topology and vCPU pinning.• Disabled AVIC/x2AVIC as an additional test. This did not change the result.Result:• OVMF now passes, unlike the earlier 6C/12T Native CPUID test.• Windows reaches 64-bit ntoskrnl, but remains on the boot screen.• All 16 vCPUs consume CPU continuously.• CPU0 remains in a small kernel loop; RIP changes only within the same nearby instructions.• Disk I/O stops progressing.• No QEMU errors, VFIO reset failures, AMD-Vi faults, or APIC pinning errors were found.Relevant raw CPUID features include:• 0xD: host XSAVE layout• 0x80000008: 48-bit physical/virtual address capability• 0x8000000A: AMD SVM capability• 0x8000001F: SME capability• 0x80000026: AMD extended topologyThe host/libvirt does not support SEV or launchSecurity, so the VM cannot fully provide every platform capability exposed by raw host CPUID.My conclusion is that Native CPUID bypasses QEMU/KVM’s filtered CPU contract. Even with matching core/thread count and APIC IDs, Windows sees CPUID features that are not fully consistent with the virtual XSAVE, MSR, memory-encryption, firmware, and ACPI platform state.Do you have a known stable approach for Native CPUID on AMD KVM with Windows, or guidance on which CPUID/MSR/platform capabilities must remain intercepted or emulated to avoid this Windows kernel spin?
Best regards,

[meowdiocre]

are you using standard qemu / edk2 or custom ?

[qiusheng-aim]

are you using standard qemu / edk2 or custom ?

I am using custom builds, not fully stock QEMU/EDK2.

QEMU:

• Custom-built QEMU 11.0.2 installed under /opt/qemu-11.0.2-vfio-wmi.
• It includes anti-detection-oriented changes mainly around SMBIOS/ACPI/QEMU strings, device identity, WMI/sensor/SMBIOS table behavior, and disk/NIC presentation.
• The normal stable configuration uses KVM hidden / hypervisor bit disabled through libvirt XML, with host-passthrough CPU and aes disabled.

EDK2/OVMF:

• I am also using a custom/non-default OVMF image:
  /var/lib/libvirt/ovmf-custom/OVMF_CODE.win11.compat.fd
• Secure Boot is disabled.
• The OVMF image was adjusted for compatibility with the VFIO passthrough setup.

Kernel:

• The Native CPUID test was done with a custom AMD SVM/KVM kernel modification inspired by devirtz-kernel, specifically clearing INTERCEPT_CPUID.
• The stable baseline does not use Native CPUID; it uses the normal CPUID interception path.

So the failing Native CPUID test was not on a completely standard QEMU/EDK2 stack. If useful, I can also reproduce the same test with stock Arch QEMU + stock edk2-ovmf to separate QEMU/OVMF issues from the KVM Native CPUID behavior.

[meowdiocre]

are you using standard qemu / edk2 or custom ?

I am using custom builds, not fully stock QEMU/EDK2.

QEMU:

* Custom-built QEMU 11.0.2 installed under /opt/qemu-11.0.2-vfio-wmi.

* It includes anti-detection-oriented changes mainly around SMBIOS/ACPI/QEMU strings, device identity, WMI/sensor/SMBIOS table behavior, and disk/NIC presentation.

* The normal stable configuration uses KVM hidden / hypervisor bit disabled through libvirt XML, with host-passthrough CPU and aes disabled.

EDK2/OVMF:

* I am also using a custom/non-default OVMF image:
  /var/lib/libvirt/ovmf-custom/OVMF_CODE.win11.compat.fd

* Secure Boot is disabled.

* The OVMF image was adjusted for compatibility with the VFIO passthrough setup.

Kernel:

* The Native CPUID test was done with a custom AMD SVM/KVM kernel modification inspired by devirtz-kernel, specifically clearing INTERCEPT_CPUID.

* The stable baseline does not use Native CPUID; it uses the normal CPUID interception path.

So the failing Native CPUID test was not on a completely standard QEMU/EDK2 stack. If useful, I can also reproduce the same test with stock Arch QEMU + stock edk2-ovmf to separate QEMU/OVMF issues from the KVM Native CPUID behavior.

did ur rdtsc/p intercepted or passthrough?

arch/x86/kvm/x86.c

if (unlikely(vcpu->cpu != cpu) || kvm_check_tsc_unstable()) {
    s64 tsc_delta = !vcpu->arch.last_host_tsc ? 0 :
            rdtsc() - vcpu->arch.last_host_tsc;   // <- host TSC read
    if (tsc_delta < 0)                             // <- host TSC went backwards
        mark_tsc_unstable("KVM discovered backwards TSC");

maybe its something related to backward-tsc

quoted from vmaware 2.7.0

Bypassers also discovered how to boot the VM with CPUID interception disabled from the very beginning, as it was simply an MSR issue with some of the MCE banks that were #GPing and bringing down the guest during early boot

in my laptop with amd this patches is working with some patches also in edk and qemu itself, you may research it more in urs

[meowdiocre]

i should recomending you to use windows 10 thou since windows 11 enforce hvci so u need to support nested virtualization.