Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 622723 - Getting inconsistent IRQ value after executed the command "info pci" in qemu and executed the command "lspci -vvv" in guest.
Getting inconsistent IRQ value after executed the command "info pci" in qemu...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Alex Williamson
Virtualization Bugs
: RHELNAK
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-10 05:27 EDT by juzhang
Modified: 2010-11-11 14:30 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-13 14:59:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description juzhang 2010-08-10 05:27:02 EDT
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.
Comment 2 RHEL Product and Program Management 2010-08-10 05:58:31 EDT
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. **
Comment 3 Alex Williamson 2010-10-13 14:59:58 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.