Bug 1421988
| Summary: | [virtio-win][virtio-input] Read wrong device in guest's device manager when do hot-plug a mouse device and keyboard device | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | xiagao | ||||||
| Component: | virtio-win | Assignee: | Ladi Prosek <lprosek> | ||||||
| virtio-win sub component: | virtio-win-prewhql | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||||
| Severity: | high | ||||||||
| Priority: | high | CC: | ailan, lijin, lmiksik, michen, phou, wyu, xiagao | ||||||
| Version: | 7.4 | ||||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-08-01 12:55:38 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
I randomly hit this issue on win2016 guest. when hotplug a virtio-mouse-pci,the device will be added into "Keyboards" devices,mouse can not work. I remember seeing something similar during development. Windows seems to cache the HID report descriptor and if the same device (as far as PCI IDs go) is plugged in it simply reuses the old descriptor, which may result in the device appearing under the wrong category and not working. I don't see it when I follow the steps in comment 0, though. I would expect the different device class - 0x0900 for virtio-keyboard-pci and 0x0902 for virtio-mouse-pci - to be enough for Windows to realize that the descriptor should be re-queried. Can you please try the following: When the guest gets into the state where a wrong device is added, remove the mouse or keyboard device in Device Manager (do not remove the VirtIO Input Driver) and then click Action->Scan for hardware changes and see if that fixes it or if the wrong device returns. Thanks! (In reply to Ladi Prosek from comment #3) > I remember seeing something similar during development. Windows seems to > cache the HID report descriptor and if the same device (as far as PCI IDs > go) is plugged in it simply reuses the old descriptor, which may result in > the device appearing under the wrong category and not working. > > I don't see it when I follow the steps in comment 0, though. I would expect > the different device class - 0x0900 for virtio-keyboard-pci and 0x0902 for > virtio-mouse-pci - to be enough for Windows to realize that the descriptor > should be re-queried. > > Can you please try the following: > When the guest gets into the state where a wrong device is added, remove the > mouse or keyboard device in Device Manager (do not remove the VirtIO Input > Driver) and then click Action->Scan for hardware changes and see if that > fixes it or if the wrong device returns. Thanks! Yes, the wrong device returns as your steps. Detailed steps: 1. boot up win7-32 guest without any input device, the input driver was installed before. 2. hot-plug a mouse device, HID Keyboard Device appeared under keyboards category and not working. 3. right-click the HID Keyboard Device and select uninstall 4. click Action->Scan for hardware changes 5. the HID compliant mouse device appeared in Mice and other pointing devices category and working. Besides, when i hot-plug keyboard device at firstly, and then hot-plug mouse or tablet device, there is no problem and all working. I can reproduce it on my host now, thank you! I can reproduce this by following the steps in comment 4 on Win7 and Win8. Win10 seems to be working fine (haven't tested Win8.1). There is nothing wrong with the driver per se - it builds the right HID report descriptor describing a mouse or a keyboard depending on what was hot-plugged. The class driver asks for the descriptor and the miniport returns it. Unfortunately, hidclass.sys decides to use an old descriptor pulled from the driver the first time the device was seen in the particular PCI slot. That's why it's order sensitive. If virtio-mouse-pci is hot-plugged in a PCI slot which previously had virtio-keyboard-pci, things break. If it ends up in a slot which had virtio-mouse-pci, it works. This is also related to bug 1422365. All these virtio-input devices share the same device/vendor ID so it's kind of reasonable of Windows to cache the descriptor because to a large extent all these devices look the same. I tried a few things to add some kind of differentiation to the driver, hoping that it would help Windows realize that it should invalidate its cache, but haven't succeeded. For a moment I thought that a different HID VID/PID returned in response to IOCTL_HID_GET_DEVICE_ATTRIBUTES would do the trick but it doesn't. I'll keep exploring our options. Will probably try to reverse-engineer Win7 hidclass.sys to understand what it's doing. Question for lijin: Are you 100% sure that you saw this on Win2016? Do you happen to have reliable repro steps? Question for xiagao: In my VMs, removing the wrong child FDO (e.g. "HID-compliant mouse") and then hitting "Scan for hardware changes" fixes it. In comment 4 you indicated that the wrong device returns for you. Can you please double-check? Thanks! Ladi (In reply to Ladi Prosek from comment #11) > I can reproduce this by following the steps in comment 4 on Win7 and Win8. > Win10 seems to be working fine (haven't tested Win8.1). > > There is nothing wrong with the driver per se - it builds the right HID > report descriptor describing a mouse or a keyboard depending on what was > hot-plugged. The class driver asks for the descriptor and the miniport > returns it. Unfortunately, hidclass.sys decides to use an old descriptor > pulled from the driver the first time the device was seen in the particular > PCI slot. That's why it's order sensitive. If virtio-mouse-pci is > hot-plugged in a PCI slot which previously had virtio-keyboard-pci, things > break. If it ends up in a slot which had virtio-mouse-pci, it works. > > This is also related to bug 1422365. All these virtio-input devices share > the same device/vendor ID so it's kind of reasonable of Windows to cache the > descriptor because to a large extent all these devices look the same. > > > I tried a few things to add some kind of differentiation to the driver, > hoping that it would help Windows realize that it should invalidate its > cache, but haven't succeeded. For a moment I thought that a different HID > VID/PID returned in response to IOCTL_HID_GET_DEVICE_ATTRIBUTES would do the > trick but it doesn't. > > I'll keep exploring our options. Will probably try to reverse-engineer Win7 > hidclass.sys to understand what it's doing. > > > Question for lijin: Are you 100% sure that you saw this on Win2016? Do you > happen to have reliable repro steps? > > Question for xiagao: In my VMs, removing the wrong child FDO (e.g. > "HID-compliant mouse") and then hitting "Scan for hardware changes" fixes > it. In comment 4 you indicated that the wrong device returns for you. Can > you please double-check? Hi Ladi, From step 5 in comment 4, i mean the right device returns and it is working. :) > > Thanks! > Ladi (In reply to Ladi Prosek from comment #11) > Question for lijin: Are you 100% sure that you saw this on Win2016? Do you > happen to have reliable repro steps? Yes,I'm sure that I hit this issue on windows 2016. Following is my steps,but it's not 100% repro,mostly keyboard does not work,mouse does not work randomly: 1.boot guest with keyboard and mouse,both work well: (qemu) info pci Bus 0, device 4, function 0: Keyboard: PCI device 1af4:1052 IRQ 0. BAR1: 32 bit memory at 0xfebf1000 [0xfebf1fff]. BAR4: 64 bit prefetchable memory at 0xfe000000 [0xfe003fff]. id "kbd0" Bus 0, device 5, function 0: Mouse: PCI device 1af4:1052 IRQ 0. BAR1: 32 bit memory at 0xfebf2000 [0xfebf2fff]. BAR4: 64 bit prefetchable memory at 0xfe004000 [0xfe007fff]. id "mouse0" 2.hot-unplug keyboard and mouse0: (qemu) device_del kbd0 (qemu) device_del mouse0 3.hot-plug mouse first and then keyboard(pci address changed),both work well (qemu) device_add virtio-mouse-pci,id=mouse0 (qemu) device_add virtio-keyboard-pci,id=kbd0 (qemu) info pci Bus 0, device 4, function 0: Mouse: PCI device 1af4:1052 IRQ 0. BAR1: 32 bit memory at 0xfebf1000 [0xfebf1fff]. BAR4: 64 bit prefetchable memory at 0xfe000000 [0xfe003fff]. id "mouse0" Bus 0, device 5, function 0: Keyboard: PCI device 1af4:1052 IRQ 0. BAR1: 32 bit memory at 0xfebf2000 [0xfebf2fff]. BAR4: 64 bit prefetchable memory at 0xfe004000 [0xfe007fff]. id "kbd0" 4.shutdown guest 5.boot guest again with same qemu command line with step1(pci address change back) (qemu) info pci Bus 0, device 4, function 0: Keyboard: PCI device 1af4:1052 IRQ 11. BAR1: 32 bit memory at 0xfebf1000 [0xfebf1fff]. BAR4: 64 bit prefetchable memory at 0xfe000000 [0xfe003fff]. id "kbd0" Bus 0, device 5, function 0: Mouse: PCI device 1af4:1052 IRQ 10. BAR1: 32 bit memory at 0xfebf2000 [0xfebf2fff]. BAR4: 64 bit prefetchable memory at 0xfe004000 [0xfe007fff]. id "mouse0" 6.guest keyboard and mouse do NOT work; hot-unplug keyboard in order to login windows2016 (qemu) device_del kbd0 Check in device manager,the mouse goes into "Keyboard"(please check attachment1 [details]) 7.Hotplug keyboard: (qemu) device_add virtio-keyboard-pci,id=kbd0 Check in device manager,the keyboard device goes into "Mice and other pointing devics" and there is a yellow alarm on the device(please check attachment2 [details]) (In reply to xiagao from comment #12) > (In reply to Ladi Prosek from comment #11) > > Question for xiagao: In my VMs, removing the wrong child FDO (e.g. > > "HID-compliant mouse") and then hitting "Scan for hardware changes" fixes > > it. In comment 4 you indicated that the wrong device returns for you. Can > > you please double-check? > > Hi Ladi, > > From step 5 in comment 4, i mean the right device returns and it is working. > :) Got it, thanks! I believe that the issue is now understood. The problem is that when hidclass.sys creates child PDOs (which I mistakenly referred to as "child FDOs" in my previous comments), it uses fixed instance IDs that do not reflect the HID report descriptor, or anything constructed from it. For example, in my test VM, the HID PDO created by hidclass for VirtioInput plugged in the first PCI slot, be it a mouse or keyboard, always gets this instance path: HID\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\4&208D8E0D&1&0000 Instance paths are cached and the PNP manager reuses the previous device node when it sees the same path again. Thus the issue we're seeing. The cleanest way to fix seems to be switching vioinput.sys from filter driver to bus driver which always enumerates one child with a unique instance ID based on the report descriptor. viohidkmdf.sys would then bind to this child as its FDO and forward HID IOCTLs back to the parent. Instance paths would then look like so: HID\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\<report descriptor hash>\4&208D8E0D&1&0000 Fixed in the upstream GitHub repo. https://github.com/virtio-win/kvm-guest-drivers-windows/commit/a2943d499bfb8ad91f191062506fe927ba624f6b Verified this issue with virtio-win-prewhql-134. Steps as comment#0 and comment#13. After do hot-plug a mouse device and keyboard device, the correct device show in guest's device manager, and the keyboard & mouse work well. change status to verified according to comment#19 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2341 |
Description of problem: Read wrong device in guest's device manager when do hot-plug a mouse device and keyboard device Version-Release number of selected component (if applicable): qemu-kvm-rhev-2.8.0-4.el7.x86_64 kernel-3.10.0-563.el7.x86_64 seabios-1.10.1-2.el7.x86_64 virtio-win-prewhql-132 How reproducible: 100% Steps to Reproduce: 1.boot up guest without mouse and keyboard device,and virtio-input driver is installed. /usr/libexec/qemu-kvm -name win7-32 -nodefaults -vga std -m 3G -smp 4 -drive file=win7-32.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/en_windows_7_ultimate_with_sp1_x86_dvd_u_677460.iso,if=none,readonly=on,media=cdrom,format=raw,id=cdrom1 -device ide-drive,drive=cdrom1,bus=ide.0,unit=1,id=ide-cd1,bootindex=0 -drive file=/home/virtio-win-prewhql-132.iso,if=none,readonly=on,media=cdrom,format=raw,id=cdrom2 -device ide-drive,drive=cdrom2,bus=ide.1,unit=0,id=ide-cd2 -vnc :0 -rtc base=localtime,clock=host,driftfix=slew -boot order=cd,menu=on -enable-kvm -monitor stdio -qmp tcp:0:1234,server,nowait -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:0a:5c:f1:1c 2.hotplug a mouse device from qmp monitor {"execute":"device_add","arguments":{"driver":"virtio-mouse-pci","id":"mouse0","serial":"virtio-mouse"}} {"return": {}} 3.check device in guest run=>devmgmt.msc 4.hotplug a keyboard device from qmp monitor {"execute":"device_add","arguments":{"driver":"virtio-keyboard-pci","id":"kbd0","serial":"virtio-keyboard"}} {"return": {}} 5.check device in guest run=>devmgmt.msc Actual results: after step 3, a HID Keyboard Device device was added in keyboards tab after step 5, a HID compliant mouse device was added in Mice and other pointing devices tab. Expected results: after step 3, the HID compliant mouse device was added in Mice and other pointing devices tab. after step 5, the HID Keyboard Device device was added in keyboards tab Additional info: