| Summary: | KVM internal error when shutting down guest with multi-monitor spice session | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Marian Krcmarik <mkrcmari> | ||||
| Component: | kernel | Assignee: | David Blechter <dblechte> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2 | CC: | knoel, kraxel | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-11-18 14:53:08 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Marian Krcmarik
2012-02-07 19:29:21 UTC
Created attachment 560041 [details]
backtrace from PAUSED qemu-kvm process
When guest is paused after the error do "x/i $rip" in the monitor. (In reply to comment #2) > When guest is paused after the error do "x/i $rip" in the monitor. virsh # qemu-monitor-command Win7 --hmp "x/i $rip" unknown register This? (In reply to comment #4) > (In reply to comment #2) > > When guest is paused after the error do "x/i $rip" in the monitor. > > virsh # qemu-monitor-command Win7 --hmp "x/i $rip" > unknown register > > This? May be it is $eip. Or just copy rip address from the register dump. For the dump from comment #1 it will be: "x/i 0xac2e69c6" (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > When guest is paused after the error do "x/i $rip" in the monitor. > > > > virsh # qemu-monitor-command Win7 --hmp "x/i $rip" > > unknown register > > > > This? > > May be it is $eip. Or just copy rip address from the register dump. For the > dump from comment #1 it will be: "x/i 0xac2e69c6" virsh # qemu-monitor-command Win7 --hmp "x/i $eip" 0x00000000ac2e69c6: movntdq %xmm0,(%edi) virsh # qemu-monitor-command Win7 --hmp "x/i 0xac2e69c6" 0x00000000ac2e69c6: movntdq %xmm0,(%edi) (In reply to comment #6) > virsh # qemu-monitor-command Win7 --hmp "x/i 0xac2e69c6" > 0x00000000ac2e69c6: movntdq %xmm0,(%edi) Can you also provide output of "info pci" monitor command for the guest? (In reply to comment #7) > (In reply to comment #6) > > virsh # qemu-monitor-command Win7 --hmp "x/i 0xac2e69c6" > > 0x00000000ac2e69c6: movntdq %xmm0,(%edi) > > Can you also provide output of "info pci" monitor command for the guest? qemu-monitor-command Win7 --hmp "info pci" Bus 0, device 0, function 0: Host bridge: PCI device 8086:1237 id "" Bus 0, device 1, function 0: ISA bridge: PCI device 8086:7000 id "" Bus 0, device 1, function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xc000 [0xc00f]. id "" Bus 0, device 1, function 2: USB controller: PCI device 8086:7020 IRQ 11. BAR4: I/O at 0xc020 [0xc03f]. id "" Bus 0, device 1, function 3: Bridge: PCI device 8086:7113 IRQ 9. id "" Bus 0, device 2, function 0: VGA controller: PCI device 1b36:0100 IRQ 10. BAR0: 32 bit memory at 0xf0000000 [0xf3ffffff]. BAR1: 32 bit memory at 0xe0000000 [0xe3ffffff]. BAR2: 32 bit memory at 0xf4000000 [0xf4001fff]. BAR3: I/O at 0xc040 [0xc05f]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. id "" Bus 0, device 3, function 0: Ethernet controller: PCI device 10ec:8139 IRQ 5. BAR0: I/O at 0xc100 [0xc1ff]. BAR1: 32 bit memory at 0xf4020000 [0xf40200ff]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. id "net0" Bus 0, device 4, function 0: Class 0403: PCI device 8086:2668 IRQ 11. BAR0: 32 bit memory at 0xffffffffffffffff [0x00003ffe]. id "sound0" Bus 0, device 5, function 0: RAM controller: PCI device 1af4:1002 IRQ 10. BAR0: I/O at 0xc200 [0xc21f]. id "balloon0" Bus 0, device 6, function 0: Class 0780: PCI device 1af4:1003 IRQ 10. BAR0: I/O at 0xffffffffffffffff [0x001e]. BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. id "virtio-serial0" Bus 0, device 7, function 0: Display controller: PCI device 1b36:0100 IRQ 5. BAR0: 32 bit memory at 0xffffffffffffffff [0x03fffffe]. BAR1: 32 bit memory at 0xffffffffffffffff [0x03fffffe]. BAR2: 32 bit memory at 0xffffffffffffffff [0x00001ffe]. BAR3: I/O at 0xffffffffffffffff [0x001e]. id "video1" Bus 0, device 8, function 0: Display controller: PCI device 1b36:0100 IRQ 11. BAR0: 32 bit memory at 0xec000000 [0xefffffff]. BAR1: 32 bit memory at 0xf5000000 [0xf5ffffff]. BAR2: 32 bit memory at 0xf6000000 [0xf6001fff]. BAR3: I/O at 0xc260 [0xc27f]. id "video2" Bus 0, device 9, function 0: Display controller: PCI device 1b36:0100 IRQ 10. BAR0: 32 bit memory at 0xf8000000 [0xfbffffff]. BAR1: 32 bit memory at 0xfd000000 [0xfdffffff]. BAR2: 32 bit memory at 0xf6002000 [0xf6003fff]. BAR3: I/O at 0xc280 [0xc29f]. id "video3 Here are finding after long IRC debug session: The instruction that fails is movntdq %xmm0,(%edi) and we indeed do not emulate it, but it should not be used to do mmio usually. The instruction tries to access address in %edi (0xddeb800). After walking page table we saw that it maps to a physical address 0xeb400000. Looking at "info pci" output in comment #8 there is no pci device that claims this address, but there is one unconfigured QXL at device 7. After reboot this device look like: Bus 0, device 7, function 0: Display controller: PCI device 1b36:0100 IRQ 5. BAR0: 32 bit memory at 0xe8000000 [0xebffffff]. BAR1: 32 bit memory at 0xe4000000 [0xe7ffffff]. BAR2: 32 bit memory at 0xf4046000 [0xf4047fff]. BAR3: I/O at 0xc240 [0xc25f]. id "video1" So it claims the address movntdq instruction tried to access. It looks like QXL driver tries to access device's memory after it is unconfigured. During normal operation such accesses are not emulated since QXL bars are memory, not mmio. Gleb indicates in this IRC chat that the fix should be in the qlx driver. <gleb_> knoel_wfh: and 788227 is technically is kvm bug since we do not emulate the mmx instruction, but it triggers due to windows driver bug <gleb_> knoel_wfh: and for rhel6 we'd rather fix it in Windows driver <knoel_wfh> gleb_: Which windows driver? <gleb_> knoel_wfh: qxl is our driver Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. closing as WONTFIx. This bug is about multiple qxl devices, and is not supported any more. |