[Qemu-devel] pci irq confusion

[Qemu-devel] pci irq confusion

[Gerd Hoffmann]

   Hi,

I've looked at the pci irqs for my virtual machine and figured it isn't 
consistent.  Look:

This is what the "info pci" monitor command prints (trimmed a bit for 
better readability):

(qemu) info pci
   Bus  0, device   1, function 2:
     USB controller: PCI device 8086:7020
       IRQ 9.
   Bus  0, device   1, function 3:
     Bridge: PCI device 8086:7113
       IRQ 11.
   Bus  0, device   3, function 0:
     Class ff80: PCI device 5853:0001
       IRQ 11.
   Bus  0, device   4, function 0:
     SCSI controller: PCI device 1000:0012
       IRQ 9.
   Bus  0, device   5, function 0:
     Storage controller: PCI device 1af4:1001
       IRQ 11.
   Bus  0, device   6, function 0:
     RAM controller: PCI device 1af4:1002
       IRQ 9.

This is what lspci says (also trimmed):

00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB 
[Natoma/Triton II] (rev 01) (prog-if 00 [UHCI])
         Flags: bus master, fast devsel, latency 64, IRQ 9

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
         Flags: medium devsel, IRQ 9

00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
         Flags: fast devsel, IRQ 11

00:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a
         Flags: bus master, fast devsel, latency 255, IRQ 9

00:05.0 Mass storage controller: Qumranet, Inc. Virtio block device
         Flags: fast devsel, IRQ 10

00:06.0 RAM memory: Qumranet, Inc. Unknown device 1002
         Flags: fast devsel, IRQ 9

And finally the output from /proc/interrupts (i.e. what irq the drivers 
are registered for):

   9:     197541   IO-APIC-level  uhci_hcd:usb1, virtio1, sym53c8xx
  10:        224   IO-APIC-level  virtio0
  11:       2159   IO-APIC-level  acpi, xen-platform-pci

Putting the three info sources into a table gives this picture:

                         |  qemu  |  lspci  |  driver
------------------------+--------+---------+----------
00:01.2  usb            |    9   |     9   |     9
00:01.3  acpi           |   11   |     9   |    11
00:03.0  xen-platform   |   11   |    11   |    11
00:04.0  scsi           |    9   |     9   |     9
00:05.0  virtio-blk     |   11   |    10   |    10
00:06.0  virtio-baloon  |    9   |     9   |     9

Note the inconsistencies for acpi and virtio-blk.  Where do they come 
from?  Is that normal?  Or is that something which needs fixing?

cheers,
   Gerd

Re: [Qemu-devel] pci irq confusion

[Ed Swierk]

On Fri, May 15, 2009 at 1:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Putting the three info sources into a table gives this picture:
>
>                        |  qemu  |  lspci  |  driver
> ------------------------+--------+---------+----------
> 00:01.2  usb            |    9   |     9   |     9
> 00:01.3  acpi           |   11   |     9   |    11
> 00:03.0  xen-platform   |   11   |    11   |    11
> 00:04.0  scsi           |    9   |     9   |     9
> 00:05.0  virtio-blk     |   11   |    10   |    10
> 00:06.0  virtio-baloon  |    9   |     9   |     9
>
> Note the inconsistencies for acpi and virtio-blk.  Where do they come from?
>  Is that normal?  Or is that something which needs fixing?

qemu's "info pci" monitor command gets the IRQ value from offset 0x3c
in the device's PCI config space, which is a useless scratch register.
Some BIOSes may write to this register the actual IRQ assigned to the
device, but many don't, and I don't know of any OS that relies on it.
IMHO this IRQ value is misleading and shouldn't be reported by qemu at
all.

lspci reads IRQ info for each device from sysfs, and represents the
IRQ on which Linux would expect to receive device interrupts if the
driver requested PCI interrupts. /proc/interrupts shows the IRQs that
have actually been associated with device drivers that requested them,
PCI or otherwise.

I'm no expert on ACPI but it appears that the Linux ACPI driver
doesn't use PCI interrupts, and is instead assigned an IRQ through
some other means; the PCI IRQ that Linux happens to associate with
device 00:01.3 is never used.

--Ed

Re: [Qemu-devel] pci irq confusion

[M. Warner Losh]

In message: <9ae48b020905181024p15b3207fy7ea7eb62b868ec0b@mail.gmail.com>
            Ed Swierk <eswierk@aristanetworks.com> writes:
: On Fri, May 15, 2009 at 1:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
: > Putting the three info sources into a table gives this picture:
: >
: >                        |  qemu  |  lspci  |  driver
: > ------------------------+--------+---------+----------
: > 00:01.2  usb            |    9   |     9   |     9
: > 00:01.3  acpi           |   11   |     9   |    11
: > 00:03.0  xen-platform   |   11   |    11   |    11
: > 00:04.0  scsi           |    9   |     9   |     9
: > 00:05.0  virtio-blk     |   11   |    10   |    10
: > 00:06.0  virtio-baloon  |    9   |     9   |     9
: >
: > Note the inconsistencies for acpi and virtio-blk.  Where do they come from?
: >  Is that normal?  Or is that something which needs fixing?
: 
: qemu's "info pci" monitor command gets the IRQ value from offset 0x3c
: in the device's PCI config space, which is a useless scratch register.
: Some BIOSes may write to this register the actual IRQ assigned to the
: device, but many don't, and I don't know of any OS that relies on it.
: IMHO this IRQ value is misleading and shouldn't be reported by qemu at
: all.

I know that all the BSDs (and I thought Linux) require the scratch
register to be correct, if it isn't 0xff...

Warner