Bug 2059795

Summary: Windows guests with some random set of Hyper-V enlightenments can not boot normally in 'strict' mode
Product: Red Hat Enterprise Linux 9 Reporter: menli <menli>
Component: qemu-kvmAssignee: Vitaly Kuznetsov <vkuznets>
qemu-kvm sub component: CPU Models QA Contact: Peixiu Hou <phou>
Status: NEW --- Docs Contact:
Severity: medium    
Priority: medium CC: coli, jinzhao, juzhang, nilal, qizhu, virt-maint, vkuznets
Version: 9.0Keywords: Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Windows   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description menli@redhat.com 2022-03-02 02:49:19 UTC
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.

Comment 1 Vitaly Kuznetsov 2022-03-02 13:34:19 UTC
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.

Comment 2 Vitaly Kuznetsov 2022-03-14 12:07:12 UTC
It seems Windows Server 2019 tries using 'hv-vpindex' even when it's not exposed.

Comment 5 Peixiu Hou 2023-03-09 09:52:16 UTC
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

Comment 6 Peixiu Hou 2023-03-28 02:35:27 UTC
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

Comment 7 Vitaly Kuznetsov 2023-03-28 13:14:26 UTC
(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.

Comment 8 Peixiu Hou 2023-03-29 01:41:06 UTC
(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

Comment 11 Peixiu Hou 2023-08-03 09:23:13 UTC
Hi Vitaly, 

Could you help to extend the Stale Date if we also have fix plan?

Thanks~
Peixiu

Comment 12 Vitaly Kuznetsov 2023-08-03 09:52:23 UTC
(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.

Comment 13 Peixiu Hou 2023-08-03 10:05:31 UTC
(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~