RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 622723 - Getting inconsistent IRQ value after executed the command "info pci" in qemu and executed the command "lspci -vvv" in guest.
Summary: Getting inconsistent IRQ value after executed the command "info pci" in qemu...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Alex Williamson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-10 09:27 UTC by juzhang
Modified: 2010-11-11 19:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-13 18:59:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description juzhang 2010-08-10 09:27:02 UTC
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 Program Management 2010-08-10 09:58:31 UTC
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 18:59:58 UTC
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.