Bug 2178384
| Summary: | broken usb tablet after cpu hotplug on Win2022 guest | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Peixiu Hou <phou> |
| Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> |
| qemu-kvm sub component: | USB | QA Contact: | yduan |
| Status: | CLOSED MIGRATED | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | chayang, coli, jinzhao, juzhang, kraxel, mkedzier, nanliu, nilal, qizhu, vgoyal, virt-maint, vkuznets, xuwei, yduan, zhguo |
| Version: | 9.2 | Keywords: | MigratedToJIRA |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | 9.2 | ||
| 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: | 2023-09-22 13:26:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
*** Bug 2178385 has been marked as a duplicate of this bug. *** Tried with ide(system disk type) + Win2022 guest + seabios, also reproduced this issue, others steps were same with comment#0. Hi all,
I do more tests for this issue, I found it's related to the usb, test summary as follows:
1) Tested with the command "-device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \", reproduced this issue easily.
2) Tested with the qemu-xhci + usb-tablet, cannot reproduce this issue.
commands as:
-device '{"id": "pcie-root-port-1", "port": 1, "driver": "pcie-root-port", "addr": "0x2.0x1", "bus": "pcie.0", "chassis": 2}' \
-device '{"driver": "qemu-xhci", "id": "usb1", "bus": "pcie-root-port-1", "addr": "0x0"}' \
-device '{"driver": "usb-tablet", "id": "usb-tablet1", "bus": "usb1.0", "port": "1"}' \
3) Tested without the usb uhci/xhci device and usb-tablet, cannot reproduce this issue.
Comamnds as:
/usr/libexec/qemu-kvm \
-name 'installer' \
-sandbox on \
-machine q35,memory-backend=mem-machine_mem \
-device '{"id": "pcie-root-port-0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x2", "chassis": 1}' \
-device '{"id": "pcie-pci-bridge-0", "driver": "pcie-pci-bridge", "addr": "0x0", "bus": "pcie-root-port-0"}' \
-nodefaults \
-device '{"driver": "VGA", "bus": "pcie.0", "addr": "0x4"}' \
-m 5120 \
-object '{"size": 5368709120, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}' \
-smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \
-cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.3,addr=0x0 \
-blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2,aio=threads,discard=unmap \
-blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \
-device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0,write-cache=on \
-device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.4 \
-netdev tap,id=id23ZUK6,vhost=on \
-vnc :2 \
-rtc base=localtime,clock=host,driftfix=slew \
-boot order=cdn,once=c,menu=off,strict=off \
-enable-kvm \
-qmp tcp:0:1232,server,nowait \
-monitor stdio \
-device vmcoreinfo \
Best Regards~
Peixiu
As the comment#3, I changed the component to USB. any questions please feel free to let me know~ Thanks~ Peixiu Make up all qemu-kvm commands for each comment#3 tests,others test steps as comment#0. 1) Tested with the command "-device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \", reproduced this issue easily. /usr/libexec/qemu-kvm \ -name 'installer' \ -sandbox on \ -machine q35,memory-backend=mem-machine_mem \ -device '{"id": "pcie-root-port-0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x2", "chassis": 1}' \ -device '{"id": "pcie-pci-bridge-0", "driver": "pcie-pci-bridge", "addr": "0x0", "bus": "pcie-root-port-0"}' \ -nodefaults \ -device '{"driver": "VGA", "bus": "pcie.0", "addr": "0x4"}' \ -m 5120 \ -object '{"size": 5368709120, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}' \ -smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \ -cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.3,addr=0x0 \ -blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2,aio=threads,discard=unmap \ -blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \ -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0,write-cache=on \ -device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.4 \ -netdev tap,id=id23ZUK6,vhost=on \ -vnc :2 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -qmp tcp:0:1232,server,nowait \ -monitor stdio \ -device vmcoreinfo \ -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \ 2) Tested with the qemu-xhci + usb-tablet, cannot reproduce this issue. commands as: /usr/libexec/qemu-kvm \ -name 'installer' \ -sandbox on \ -machine q35,memory-backend=mem-machine_mem \ -device '{"id": "pcie-root-port-0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x2", "chassis": 1}' \ -device '{"id": "pcie-pci-bridge-0", "driver": "pcie-pci-bridge", "addr": "0x0", "bus": "pcie-root-port-0"}' \ -nodefaults \ -device '{"driver": "VGA", "bus": "pcie.0", "addr": "0x4"}' \ -m 5120 \ -object '{"size": 5368709120, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}' \ -smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \ -cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.3,addr=0x0 \ -blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2,aio=threads,discard=unmap \ -blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \ -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0,write-cache=on \ -device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.4 \ -netdev tap,id=id23ZUK6,vhost=on \ -vnc :2 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -qmp tcp:0:1232,server,nowait \ -monitor stdio \ -device vmcoreinfo \ -device '{"id": "pcie-root-port-1", "port": 1, "driver": "pcie-root-port", "addr": "0x2.0x1", "bus": "pcie.0", "chassis": 2}' \ -device '{"driver": "qemu-xhci", "id": "usb1", "bus": "pcie-root-port-1", "addr": "0x0"}' \ -device '{"driver": "usb-tablet", "id": "usb-tablet1", "bus": "usb1.0", "port": "1"}' \ 3) Tested without the usb uhci/xhci device and usb-tablet, cannot reproduce this issue. Comamnds as: /usr/libexec/qemu-kvm \ -name 'installer' \ -sandbox on \ -machine q35,memory-backend=mem-machine_mem \ -device '{"id": "pcie-root-port-0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x2", "chassis": 1}' \ -device '{"id": "pcie-pci-bridge-0", "driver": "pcie-pci-bridge", "addr": "0x0", "bus": "pcie-root-port-0"}' \ -nodefaults \ -device '{"driver": "VGA", "bus": "pcie.0", "addr": "0x4"}' \ -m 5120 \ -object '{"size": 5368709120, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}' \ -smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \ -cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.3,addr=0x0 \ -blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2,aio=threads,discard=unmap \ -blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \ -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0,write-cache=on \ -device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.4 \ -netdev tap,id=id23ZUK6,vhost=on \ -vnc :2 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -qmp tcp:0:1232,server,nowait \ -monitor stdio \ -device vmcoreinfo \ Reproduced this bz with different conclusion.
Hi Peixiu, could you please help verify my conclusion? Thanks!
Description of problem:
Win2022 Guest mouse cursor got stuck after cpu hotplug operation when using uhci USB controller.
Version-Release number of selected component (if applicable):
HOST: RHEL9.2.0
Guest: Win2022
5.14.0-284.2.1.el9_2.x86_64
qemu-kvm-7.2.0-11.el9_2.x86_64
seabios-bin-1.16.1-1.el9.noarch
How reproducible:
100%
Steps to Reproduce:
1.Boot up a Win2022 guest with '-device piix3-usb-uhci,id=usb -device usb-tablet,id=input0'.
Full command line is in the end.
2.Do CPU hotplug on qmp monitor:
{ "execute": "device_add","arguments":{"driver":"Icelake-Server-noTSX-x86_64-cpu","core-id": 1, "thread-id": 0, "socket-id": 1,"id":"cpu2" }}
Actual results:
Guest mouse cursor has no response, but we can operate using keyboard.
Additional info:
1. This can be reproduced with 'piix4-usb-uhci' or 'ich9-usb-uhci6'.
2. The screenshots of Guest Device Manager info before and after doing CPU hotplug are attached.
3. Full command line:
/usr/libexec/qemu-kvm \
-name 'installer' \
-machine q35 \
-nodefaults \
-vga std \
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.4,addr=0x0 \
-blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2,aio=threads \
-blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \
-device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0 \
-device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3 \
-netdev tap,id=id23ZUK6,vhost=on \
-m 14336 \
-cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \
-no-hpet \
-smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \
-drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/ISO/Win2022/windows_server_2022_x64_testsigned_enable_dvd.iso \
-device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \
-cdrom /home/kvm_autotest_root/iso/windows/winutils.iso \
-device piix3-usb-uhci,id=usb \
-device usb-tablet,id=input0 \
-vnc :0 \
-rtc base=localtime,clock=host,driftfix=slew \
-boot order=cdn,once=c,menu=off,strict=off \
-enable-kvm \
-qmp tcp:0:1234,server,nowait \
-monitor stdio \
-device vmcoreinfo \
(In reply to yduan from comment #7) > Reproduced this bz with different conclusion. > > Hi Peixiu, could you please help verify my conclusion? Thanks! > > Description of problem: > Win2022 Guest mouse cursor got stuck after cpu hotplug operation when using > uhci USB controller. > > Version-Release number of selected component (if applicable): > HOST: RHEL9.2.0 > Guest: Win2022 > 5.14.0-284.2.1.el9_2.x86_64 > qemu-kvm-7.2.0-11.el9_2.x86_64 > seabios-bin-1.16.1-1.el9.noarch > > How reproducible: > 100% > > Steps to Reproduce: > 1.Boot up a Win2022 guest with '-device piix3-usb-uhci,id=usb -device > usb-tablet,id=input0'. > Full command line is in the end. > > 2.Do CPU hotplug on qmp monitor: > { "execute": > "device_add","arguments":{"driver":"Icelake-Server-noTSX-x86_64-cpu","core- > id": 1, "thread-id": 0, "socket-id": 1,"id":"cpu2" }} > > Actual results: > Guest mouse cursor has no response, but we can operate using keyboard. > > Additional info: > 1. This can be reproduced with 'piix4-usb-uhci' or 'ich9-usb-uhci6'. > 2. The screenshots of Guest Device Manager info before and after doing CPU > hotplug are attached. > 3. Full command line: > /usr/libexec/qemu-kvm \ > -name 'installer' \ > -machine q35 \ > -nodefaults \ > -vga std \ > -device > pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on, > addr=0x2 \ > -device > pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ > -device > pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ > -device > pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ > -device > pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ > -device > pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ > -device > pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \ > -device > pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \ > -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.4,addr=0x0 \ > -blockdev > node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off, > filename=/home/kvm_autotest_root/images/win2022-64-virtio-scsi.qcow2, > aio=threads \ > -blockdev > node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off, > file=file_image1 \ > -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0 \ > -device > virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3 \ > -netdev tap,id=id23ZUK6,vhost=on \ > -m 14336 \ > -cpu > 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed, > hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush, > hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \ > -no-hpet \ > -smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \ > -drive > id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/ > home/kvm_autotest_root/iso/ISO/Win2022/ > windows_server_2022_x64_testsigned_enable_dvd.iso \ > -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \ > -cdrom /home/kvm_autotest_root/iso/windows/winutils.iso \ > -device piix3-usb-uhci,id=usb \ > -device usb-tablet,id=input0 \ > -vnc :0 \ > -rtc base=localtime,clock=host,driftfix=slew \ > -boot order=cdn,once=c,menu=off,strict=off \ > -enable-kvm \ > -qmp tcp:0:1234,server,nowait \ > -monitor stdio \ > -device vmcoreinfo \ Thanks for your test, yes, also same with I hit~ You can correct the bug title/severity if needed~ BR~ Peixiu Given this is ... (a) not a complete system hang but non-working usb tablet only, and (b) not happening with the xhci host adapter (which is the default these days). ... severity "high" looks unjustified to me. Downgrading to "medium". Is this a regression? When connecting other usb devices (usb-storage for example) to uhci, are those devices dead too? (In reply to Gerd Hoffmann from comment #11) > Given this is ... > > (a) not a complete system hang but non-working usb tablet only, and > (b) not happening with the xhci host adapter (which is the default these > days). > > ... severity "high" looks unjustified to me. Downgrading to "medium". > > Is this a regression? > > When connecting other usb devices (usb-storage for example) to uhci, are > those devices dead too? It's weird here: After attaching a usb-storage device, everything works well including usb-tablet (before and after CPU hotplug operation). ... -device piix3-usb-uhci,id=usb \ -device usb-tablet,id=input0 \ -blockdev node-name=file_stg1,driver=file,cache.direct=on,cache.no-flush=off,filename=stg1.qcow2,aio=threads \ -blockdev node-name=drive_stg1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_stg1 \ -device usb-storage,id=usb_stick,drive=drive_stg1 \ ... (In reply to Gerd Hoffmann from comment #11) > Given this is ... > > (a) not a complete system hang but non-working usb tablet only, and > (b) not happening with the xhci host adapter (which is the default these > days). > > ... severity "high" looks unjustified to me. Downgrading to "medium". > > Is this a regression? I tested on RHEL 9.1 with piix3-usb-uhci/ich9-usb-uhci6, usb-tablet device worked well before and after CPU hotplug operation. 5.14.0-162.18.1.el9_1.x86_64 qemu-kvm-7.0.0-13.el9_1.2.x86_64 ... -device piix3-usb-uhci,id=usb \ -device usb-tablet,id=input0 \ ... So I think it's a regression. But for piix4-usb-uhci controller, usb-tablet doesn't work from startup and change to work after CPU hotplug. > > When connecting other usb devices (usb-storage for example) to uhci, are > those devices dead too? (In reply to yduan from comment #12) > (In reply to Gerd Hoffmann from comment #11) > > Given this is ... > > > > (a) not a complete system hang but non-working usb tablet only, and > > (b) not happening with the xhci host adapter (which is the default these > > days). > > > > ... severity "high" looks unjustified to me. Downgrading to "medium". > > > > Is this a regression? > > > > When connecting other usb devices (usb-storage for example) to uhci, are > > those devices dead too? > > It's weird here: > After attaching a usb-storage device, everything works well including > usb-tablet (before and after CPU hotplug operation). > ... > -device piix3-usb-uhci,id=usb \ > -device usb-tablet,id=input0 \ > -blockdev > node-name=file_stg1,driver=file,cache.direct=on,cache.no-flush=off, > filename=stg1.qcow2,aio=threads \ > -blockdev > node-name=drive_stg1,driver=qcow2,cache.direct=on,cache.no-flush=off, > file=file_stg1 \ > -device usb-storage,id=usb_stick,drive=drive_stg1 \ > ... Using ich9-usb-uhci6 got the same result. But for piix4-usb-uhci controller, usb-tablet doesn't work from startup and change to work after CPU hotplug. Hi Gerd, Please help check Comment 12, Comment 13 and Comment 14. Thanks! yduan Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |
Description of problem: System hang when do cpu hotplug on Win2022 guest. Tested with seabios mode, hit it on Win2022 guest, and did not hit on Win2019 guest. Version-Release number of selected component (if applicable): HOST: RHEL9.2.0 Guest: Win2022 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 virtio-win-prewhql-234 How reproducible: 100% Steps to Reproduce: 1.Boot the Win2022 guest up with all hv flags: /usr/libexec/qemu-kvm \ -name 'installer' \ -machine q35 \ -nodefaults \ -vga std \ -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \ -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.4,addr=0x0 \ -blockdev node-name=file_image1,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/hyper-v-run/win2022-64-virtio-scsi.qcow2,aio=threads \ -blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \ -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0 \ -blockdev node-name=file_stg1,driver=file,cache.direct=on,cache.no-flush=off,filename=stgtest1.qcow2,aio=threads \ -blockdev node-name=drive_stg1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_stg1 \ -device virtio-blk-pci,id=stg1,drive=drive_stg1,bus=pci.8,addr=0x0 \ -device virtio-net-pci,mac=9a:36:83:b6:3d:06,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3 \ -netdev tap,id=id23ZUK6,vhost=on \ -m 14336 \ -cpu 'Icelake-Server-noTSX',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_evmcs,hv_crash,hv_ipi,+kvm_pv_unhalt \ -no-hpet \ -smp 4,maxcpus=6,cores=3,threads=1,dies=1,sockets=2 \ -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/ISO/Win2022/windows_server_2022_x64_testsigned_enable_dvd.iso \ -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \ -cdrom /home/kvm_autotest_root/iso/windows/winutils.iso \ -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \ -vnc :2 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -qmp tcp:0:1232,server,nowait \ -monitor stdio \ -device vmcoreinfo \ -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 \ 2.$ telnet 10.73.72.118 1232 3.{"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 7}, "package": "qemu-kvm-7.2.0-8.el9"}, "capabilities": ["oob"]}} {"execute": "qmp_capabilities"} 4. {"execute": "query-hotpluggable-cpus"} {"return": [{"props": {"core-id": 2, "thread-id": 0, "socket-id": 1}, "vcpus-count": 1, "type": "Icelake-Server-noTSX-x86_64-cpu"}, {"props": {"core-id": 1, "thread-id": 0, "socket-id": 1}, "vcpus-count": 1, "type": "Icelake-Server-noTSX-x86_64-cpu"}, {"props": {"core-id": 0, "thread-id": 0, "socket-id": 1}, "vcpus-count": 1, "qom-path": "/machine/unattached/device[4]", "type": "Icelake-Server-noTSX-x86_64-cpu"}, {"props": {"core-id": 2, "thread-id": 0, "socket-id": 0}, "vcpus-count": 1, "qom-path": "/machine/unattached/device[3]", "type": "Icelake-Server-noTSX-x86_64-cpu"}, {"props": {"core-id": 1, "thread-id": 0, "socket-id": 0}, "vcpus-count": 1, "qom-path": "/machine/unattached/device[2]", "type": "Icelake-Server-noTSX-x86_64-cpu"}, {"props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]", "type": "Icelake-Server-noTSX-x86_64-cpu"}]} 5. On the guest, check the Processors in Device manager. There are 4 processors show out. 6. Do Cpu hotplug on qmp monitor: { "execute": "device_add","arguments":{"driver":"Icelake-Server-noTSX-x86_64-cpu","core-id": 1, "thread-id": 0, "socket-id": 1,"id":"cpu2" }} {"timestamp": {"seconds": 1678090670, "microseconds": 169066}, "event": "ACPI_DEVICE_OST", "data": {"info": {"device": "cpu2", "source": 0, "status": 0, "slot": "4", "slot-type": "CPU"}}} {"return": {}} 7. Check the processor status in windows guest device manager. There are 5 processors shown, but the system was hang, mouse cannot be moved on the desktop. 8. Try to system_reset the system, after reset, the system restore to work. 9. Try to hotplug another cpu: { "execute": "device_add","arguments":{"driver":"Icelake-Server-noTSX-x86_64-cpu","core-id": 2, "thread-id": 0, "socket-id": 1,"id":"cpu1" }} {"return": {}} {"timestamp": {"seconds": 1678090958, "microseconds": 503971}, "event": "ACPI_DEVICE_OST", "data": {"info": {"device": "cpu1", "source": 0, "status": 0, "slot": "5", "slot-type": "CPU"}}} Actual results: System hang Expected results: Smoothly pass Additional info: