qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-ppc] [PATCH 2/3] pseries: Use more conventional PCI interrupt swizzling
Date: Sun, 15 Apr 2012 15:26:08 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Apr 15, 2012 at 09:47:47PM +1000, David Gibson wrote:
> 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.

So no need to check that then :)

> > 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.

So the comment 'use standard PCI swizzling' misleads in implying the
motivation is the standard. Better remove it, or replace with real motivation.

>  Plus this scheme is basically just better - it won't force
> all the functions of a multi-function device to share an interrupt.

Only if some functions use pin != INTA. Maybe it's true for
pseries? On the pc most of them use INTA.

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



reply via email to

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