qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [RFC PATCH] qemu spapr-pci: added IRQ list to PCIBus
Date: Thu, 17 May 2012 13:00:41 +1000

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 :)

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.

> >> If we do not want pci_get_irq to return global IRQ numbers than it makes 
> >> more sense to keep using
> >> pins (A,B,C,D) plus some bus ID and not introduce any new numbers at all.
> > How does that solve the initial problem of getting the EOI?
> 
> >> How can PCIBus::pci_get_irq() _callbacks_ be useful?
> > It indicates support?  Thanks,
> 
> Flag is enough :)
> Honestly when I see a "get", I am looking for a "put" in any form. And for 
> powerpc it makes some
> sense as IRQ is set in QEMU, not from the guest.

Cheers,
Ben.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]