Description of problem: Windows guests with following set of Hyper-V enlightenments can not boot normally in 'strict' mode. eg： -cpu 'Skylake-Server',hv-enforce-cpuid,hv_vapic,hv_time,hv_runtime \ Version-Release number of selected component (if applicable): qemu-kvm-6.2.0-9.el9.x86_64 seabios-bin-1.14.0-7.el9.noarch kernel-5.14.0-32.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot the windows guest with following qemu command /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm3' \ -machine q35 \ -nodefaults \ -vga std \ -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \ -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \ -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \ -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \ -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \ -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \ -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/win2019-64-virtio.qcow2,node-name=data_node \ -blockdev driver=qcow2,node-name=data_disk,file=data_node \ -device scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \ -device virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3 \ -netdev tap,id=id23ZUK6,vhost=on \ -m 14336 \ -smp 2,maxcpus=4 \ -cpu 'Skylake-Server',hv_vapic,hv_time,hv_runtime,hv-enforce-cpuid \ -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \ -vnc :10 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -qmp tcp:0:1231,server,nowait \ -monitor stdio \ Actual results: Guest can not boot normally. Expected results: Guest can boot normally. Additional info: 1. after remove 'hv-enforce-cpuid' guest boot normally.
This is certainly an issue worth investigating, thanks! As strict mode is not enabled by default and by any layered product I'm setting ITR to 9.1.0.
It seems Windows Server 2019 tries using 'hv-vpindex' even when it's not exposed.
Reproduced this issue on RHEL9.2.0 Host. 1) With -cpu 'Icelake-Server-noTSX',hv-enforce-cpuid,hv-enforce-cpuid,hv_vapic,hv_time,hv_runtime, cannot boot into the guest. 2) With -cpu 'Icelake-Server-noTSX',hv-enforce-cpuid,hv-vpindex,hv-synic,hv-ipi, hit BSOD, reboot the guest , guest can be worked normally. 3) With -cpu 'Icelake-Server-noTSX',hv-enforce-cpuid,hv_tlbflush,hv-vpindex, works normally. Used Versions: kernel-5.14.0-249.el9.x86_64 qemu-kvm-7.2.0-8.el9.x86_64 seabios-bin-1.16.1-1.el9.noarch Guest OS:Win2022 Thanks~ Peixiu
Hi Vitaly, Do we have plan to fix this issue on RHEL 9.3.0? Just confirm that since the issue's severity is high~ Thanks~ Peixiu
(In reply to Peixiu Hou from comment #6) > Hi Vitaly, > > Do we have plan to fix this issue on RHEL 9.3.0? Just confirm that since the > issue's severity is high~ It should not be high as "hv-enforce-cpuid" is never enabled by default or by layered products and we do not recommend that. I've lowered to 'medium'. No particular plans for 9.3 yet.
(In reply to Vitaly Kuznetsov from comment #7) > (In reply to Peixiu Hou from comment #6) > > Hi Vitaly, > > > > Do we have plan to fix this issue on RHEL 9.3.0? Just confirm that since the > > issue's severity is high~ > > It should not be high as "hv-enforce-cpuid" is never enabled by default or > by layered > products and we do not recommend that. I've lowered to 'medium'. No > particular plans > for 9.3 yet. Got it, Thank you and for your explanation~ Best Regards~ Peixiu
Hi Vitaly, Could you help to extend the Stale Date if we also have fix plan? Thanks~ Peixiu
(In reply to Peixiu Hou from comment #11) > Hi Vitaly, > > Could you help to extend the Stale Date if we also have fix plan? Yes, I've already done this earlier today, it's not set to 2024-03-02 and I hope we'll get to the issue by then.
(In reply to Vitaly Kuznetsov from comment #12) > (In reply to Peixiu Hou from comment #11) > > Hi Vitaly, > > > > Could you help to extend the Stale Date if we also have fix plan? > > Yes, I've already done this earlier today, it's not set to 2024-03-02 and I > hope we'll get to the issue by then. oo, sorry, I saw the date wrong, thank you~