Re: [Qemu-ppc] [PATCH 2/3] pseries: Use more conventional PCI interrupt swizzling

[David Gibson]

On Sun, Apr 15, 2012 at 01:03:57PM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 02, 2012 at 02:17:36PM +1000, David Gibson wrote:
> > Currently the pseries PCI code uses a somewhat strange scheme of PCI irq
> > allocation - one per slot up to a maximum that's greater than the usual 4.
> > This scheme more or less worked, because we were able to tell the guest the
> > irq mapping in the device tree, however it's nonstandard and may break
> > assumptions in the future.  Worse, the array used to construct the dev
> > tree interrupt map was mis-sized, we got away with it only because it
> > happened that our SPAPR_PCI_NUM_LSI value was greater than 7.
> > 
> > This patch changes the pseries PCI code to use the normal PCI interrupt
> > swizzling scheme instead,
> 
> I don't see anything wrong with the code - I assume someone
> who applies this knows about real hardware and can check that
> it behaves as emulated here.

Because the device tree lets us advertise to the guest precisely how
the interrupts are mapped, it doesn't really matter whether we behave
identically to "real" hardware (the PAPR platform we're emulating here
is already a para-virtualized environment running under a hypervisor,
so "real" isn't a particularly clear concept).  I'm not sure if all
pseries machines (and/or hypervisor versions) are the same in this
regard, but the new scheme is certainly in use.  As long as the device
tree has the correct information, really any interrupt mapping scheme
is compliant with PAPR.

> But I don't remember any standard scheme except for bridge devices,
> and this isn't one, is it?  Care to clarify?

Well, the standard swizzling scheme is for p2p bridges, whereas this
is a host bridge, but there's no reason not to use the same scheme for
both.  This will become more important when we implement pass-through.
On pSeries the unit of passthrough can be either a host bridge or a
p2p bridge, and having the same swizzling scheme will make life
easier.  Plus this scheme is basically just better - it won't force
all the functions of a multi-function device to share an interrupt.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson