Re: [Qemu-devel] [RFC PATCH] qemu spapr-pci: added IRQ list to PCIBus

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 2012-05-17 at 13:00 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-05-17 at 12:16 +1000, Alexey Kardashevskiy wrote:
> 
> > > It actually can change dynamically on x86 due to acpi interrupt links
> > > which allow the guest a generic way to select from a set of possible
> > > interrupt routing schemes.  And of course a chipset driver could twiddle
> > > bits if it wanted as well.  So, we really do need the update notifiers
> > > from my tree that this patch drops.
> > 
> > 
> > You mean notifiers like these: ioapic_add_gsi_eoi_notifier?
> > I did not drop them, we need them so I implemented them for XICS interrupt controller.
> 
> So I haven't completely understood the problem, however:
> 
>  .../...
> 
> > So it stores global IRQs in the config space but it really unclear who writes these _global_ numbers
> > there. Is it the guest who allocates IRQs and writes the numbers into the config space so QEMU knows
> > what pin is what IRQ? If so, I am wrong, you are right :)

Yes, from the piix4 spec:

        4.1.10.
        PIRQRC[A:D]—PIRQX ROUTE CONTROL REGISTERS (FUNCTION 0)
        Address Offset: 60h (PIRQRCA#)–63h (PIRQRCD#)
        Default Value: 80h
        Attribute: R/W
        
        These registers control the routing of the PIRQ[A:D]# signals to
        the IRQ inputs of the interrupt controller. Each PIRQx# can be
        independently routed to any one of 11 interrupts. All four
        PIRQx# lines can be routed to the same IRQx input. Note that the
        IRQ that is selected through bits [3:0] must be set to level
        sensitive mode in the corresponding ELCR Register. When a PIRQ
        signal is routed to an interrupt controller IRQ, PIIX4 masks the
        corresponding IRQ signal.

Touching this register directly by the guest might be discouraged, but
we provide PCI interrupt link devices in ACPI namespace that allows the
guest to mess with this in a more indirect way.

> So you can certainly not write our global irq numbers in the config
> space, since the config space IRQ_LINE register is only 8 bits long
> which means it's not long enough.
> 
> In general we don't use that register on ppc anyways, it's just a
> storage, it should have no actual effect on HW.
> 
> The IRQ_PIN register however is important and needs to indicate
> which of the 4 interrupt lines associated with the bus the
> device will trigger, so we need to get that right especially
> vs. swizzling performed by intermediary bridges.
> 
> Here, we can either show all the bridges to the guest (emulate
> them is fine) and keep the original PIN numbers, or we need
> to filter config space to change the PIN numbers seen by the
> guest to match the lack of appropriate swizzling.

That's a different problem.  For this it doesn't matter which IRQ_PIN
the device claims to pull when signaling an interrupt so long as qemu
and the config space exposed to the guest are in agreement.  We should
be able to easily virtualize IRQ_PIN if we want to avoid swizzling
problems.  The problem here is that we've told qemu to fire the
interrupt to the guest for the device and have disabled the interrupt
for the physical device; how do we know when to re-enable it?  An
emulated device sets the interrupt level back when the guest has
interacted with the device and there's nothing left to do.  This happens
in the emulated driver code.  For an assigned device we have no idea
what guest access indicates that the interrupt is done, so we try to
take advantage of PCI using level interrupts and figure out which EOI
corresponds to the interrupt we triggered.  Thanks,

Alex