Bug 622723
| Summary: | Getting inconsistent IRQ value after executed the command "info pci" in qemu and executed the command "lspci -vvv" in guest. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | juzhang <juzhang> |
| Component: | qemu-kvm | Assignee: | Alex Williamson <alex.williamson> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.1 | CC: | llim, michen, mkenneth, virt-maint |
| Target Milestone: | rc | Keywords: | RHELNAK |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-13 18:59:58 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: | |||
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. ** This is because 'info pci' in the qemu monitor reports the value of the PCI_INTERRUPT_LINE register on the PCI device. This register is under control of the guest OS, and does not actually affect the interrupt routing of the device. Most guest OSes are ACPI aware and will instead make use of the PCI interrupt link devices that allow them to query and assign the actual GSI for the device. When they do this, they don't typically write the value back into the INTERRUPT_LINE register. Note that in the guest, you can use setpci to read the line register, which should always match 'info pci'. In step 4, you'd do: # setpci -s 00:03.0 INTERRUPT_LINE For Linux guests, you can also boot with the kernel parameter pci=noacpi, which will force the kernel to use the legacy interrupt mapping, which should then make lspci and info pci match. Also note that the device in question is using MSI interrupts, so while it's assigned an interrupt for the PCI interrupt PIN routing, it's not actually using it. If there's an actually need to try to be more precise in tracking the guest interrupt configuration, refile as an RFE. |
Description of problem: First unbind device from host.second boot guest with physical nic.After guest booted.check this nic info via command "info pci" in qemu.at last,log in guest.check this nic via command "lspci -vvv".however,Getting inconsistent IRQ value respectively executed the command "info pci" in qemu and executed the command "lspci -vvv" in guest. Version-Release number of selected component (if applicable): #rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.108.el6.x86_64 How reproducible: Steps to Reproduce: 1.Unbind device from host kernel driver (PCI device 03:00.0) #echo "8086 10b9" > /sys/bus/pci/devices/0000\:03\:00.0/driver/new_id #echo 0000:03:00.0 > /sys/bus/pci/drivers/pci-stub/unbind #echo 0000:03:00.0 > /sys/bus/pci/drivers/e1000e/bind 2.boot guest with the physical nic #/usr/libexec/qemu-kvm -m 4G -smp 2 -drive file=/root/zhangjunyi/RHEL-Server-6.0-64-virtio.qcow2,id=test,boot=on,cache=none,format=qcow2 -device ide-drive,drive=test -cpu qemu64,+sse2,+x2apic,-kvmclock -monitor stdio -boot order=cdn,menu=on -net none -vnc :9 -qmp tcp:0:4444,server,nowait -device pci-assign,host=03:00.0,id=zhangjunyi 3.Check pci info in qemu (qemu) info pci ....... Bus 0, device 3, function 0: Ethernet controller: PCI device 8086:10b9 IRQ 11. BAR0: 32 bit memory at 0xf2020000 [0xf203ffff]. BAR1: 32 bit memory at 0xf2040000 [0xf205ffff]. BAR2: I/O at 0xc020 [0xc03f]. BAR6: 32 bit prefetchable memory at 0xffffffffffffffff [0x0001fffe]. id "zhangjunyi" 4. log in guest.issue the "lspci -vvv" command #lspci -vvv ........... 00:03.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 24 Region 0: Memory at f2020000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at f2040000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at c020 [size=32] Expansion ROM at f2060000 [disabled] [size=128K] Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00000 Data: 4059 Kernel driver in use: e1000e Kernel modules: e1000e Actual results: According to step3 display. The nic IRQ is 11.however,step4 results show that the nic IRQ is 24. Expected results: Getting the same IRQ value respectively executed the command "info pci" in qemu and executed the command "lspci -vvv" in guest. Additional info: 1. In host,this nic detailed infos as the following: #lspci -vvv 03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter Physical Slot: 1 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 55 Region 0: Memory at e3200000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at e3220000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at b000 [size=32] [virtual] Expansion ROM at e3500000 [disabled] [size=128K] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00000 Data: 40e9 Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP+ ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140] Device Serial Number 00-15-17-ff-ff-51-8d-c1 Kernel driver in use: e1000e Kernel modules: e1000e 2. I also tested window2008 64 bit guest.hit this issue too.