[SOLVED] Windows 11 bootloop with kernel 7.0 (works with kernel 6.17)

[p.b]

Dear all,

I'm posting here in hope of getting some help or advice for one of my VMs which stops working as soon as I switch to kernel 7.0 - with kernel 6.17 and before the same setup (with older machine types) worked flawlessly since ~ Proxmox 6.

The VM has some minimum hard requirements:
- Passthrough of dedicated GPU, WLAN-Card and USB-Controller
- VBS (Virtualization-based Security) and WSL2
- Proper CPU/GPU performance of ~95% bare metal which requires most Hyper-V Enlightenments as demonstrated here

When setting up the VM in 2024, I already got boot loops and Hyper-V but eventually found a solution by using args as explained here:

args: -cpu host,hv_passthrough,level=30,-waitpkg

The full VM config looks like this (redacted MACs and ID):

agent: 1
args: -smp 16,cores=8,threads=2,sockets=1 -cpu host,hv_passthrough,level=30,-waitpkg
bios: ovmf
boot: order=ide2;scsi0
cores: 16
cpu: host
efidisk0: local-zfs:vm-130-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
hookscript: local:snippets/hookscript.sh
hostpci0: 0000:00:14.3,pcie=1
hostpci1: 0000:07:00,pcie=1
hostpci2: 0000:10:00,pcie=1
ide2: none,media=cdrom
machine: pc-q35-11.0+pve2
memory: 32768
meta: creation-qemu=8.1.5,ctime=1709942094
name: apollon
net0: virtio=*,bridge=vmbr0,tag=1
net1: virtio=*,bridge=vmbr0,tag=4
numa: 0
ostype: win11
protection: 1
scsi0: local-zfs:vm-130-disk-1,aio=threads,discard=on,iothread=1,size=256G,ssd=1
scsi1: transient-zfs:vm-130-disk-0,aio=threads,discard=on,iothread=1,size=2T,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=*,manufacturer=QVNVUw==,base64=1
sockets: 1
tpmstate0: local-zfs:vm-130-disk-2,size=4M,version=v2.0
usb0: host=8087:0033,usb3=1
usb1: host=046d:c548,usb3=1
vga: none
vmgenid: *

As already mentioned, this config currently works perfectly with kernel 6.17 (even withOUT the CPU flags level=30,-waitpkg) but as soon as I switch to kernel 7.0, Windows 11 gets stuck in a boot loop and shows a BSOD with error code 0xc0000001 after several attempts (see screenshot). I already updated Proxmox to make sure all packages are up to date (2026-08-09, PVE 9.2.4, enterprise repo) and use some Intel i9-14900K + W680 hardware.

Even though not necessary with kernel 6.17, I also already tried the troubleshooting steps from the Proxmox Nested Virtualization Wiki to disable MSRs without success.

Does anyone have some recommendation, hint or ideas on how to fix or at least debug this with kernel 7.0? So far, I could not find any logs (journalctl, dmesg, etc.) related to the problem on the host. The machine just stops after some time shwoing the BSOD.

Any advice is highly appreciated - thanks in advance!

Kind regards,
Pascal

Current PVE versions pveversion -v (2026-08-09):

proxmox-ve: 9.2.0 (running kernel: 6.17.13-21-pve)
pve-manager: 9.2.4 (running version: 9.2.4/5e5ae681198514d4)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0.14-8-pve-signed: 7.0.14-8
proxmox-kernel-7.0: 7.0.14-8
proxmox-kernel-6.17: 6.17.13-21
proxmox-kernel-6.17.13-21-pve-signed: 6.17.13-21
ceph-fuse: 19.2.3-pve4
corosync: 3.1.10-pve3
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.20
libpve-guest-common-perl: 6.0.5
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.7
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.8
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.3-1
proxmox-backup-file-restore: 4.2.3-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-widget-toolkit: 5.2.6
pve-cluster: 9.1.6
pve-container: 6.1.12
pve-docs: 9.2.3
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.5
pve-firmware: 3.18-5
pve-ha-manager: 5.2.4
pve-i18n: 3.9.0
pve-qemu-kvm: 11.0.2-1
pve-xtermjs: 6.0.0-2
qemu-server: 9.2.1
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.3-pve1

 

[p.b]

It seems I just found the solution:

Checked the VM command via qm showcmd and found that it contained -cpu 'host,-cet-ibt,-cet-ss,hv_evmcs,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt' from Proxmox's limted CPU option with related defaults and -cpu 'host,-waitpkg,level=30,hv_passthrough' from my advanced args option.

Comparing both - since the latter wins over the former - basically left -cet-ibt,-cet-ss missing since all the hv_* flags are already contained in hv_passthrough and +kvm_pv_eoi,+kvm_pv_unhalt should be pulled in automatically with CPU type host (redundant).

Then I checked kvm capabilities for both kernel versions via

qemu-system-x86_64 -machine accel=kvm -display none -S -qmp stdio <<'EOF' | grep -oE '"(cet-ibt|cet-ss)": (true|false)'
{"execute":"qmp_capabilities"}
{"execute":"query-cpu-model-expansion","arguments":{"type":"full","model":{"name":"host"}}}
{"execute":"quit"}
EOF

and got

"cet-ibt": true
"cet-ss": true

with kernel 7.0 and

"cet-ibt": false
"cet-ss": false

with kernel 6.17.

After adding -cet-ibt,-cet-ss to the advanced args option, the VM did not get stuck in the bootloop anymore. So my final and working cpu args option for this particular VM now is:

args: -cpu host,-cet-ibt,-cet-ss,-waitpkg,level=30,hv_passthrough

Seems this is already mentioned in the Proxmox QEMU KVM Virtual Machines Wiki quite hidden under "Windows-related CPU settings". No idea though why kernel 6.17 and 7.0 expose different cet-* capabilties on the same hardware.

Hope this is helpful for someone else...

 

[fiona]

Hi,

No idea though why kernel 6.17 and 7.0 expose different cet-* capabilties on the same hardware.

because the feature depends on kernel support and that was newly implemented between those kernel versions. Proxmox VE already removes the flags because of the issues you encountered, but the custom args take precedence.