[Top][All Lists]
[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
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, (continued)
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Peter Maydell, 2012/04/04
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Blue Swirl, 2012/04/04
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Peter Maydell, 2012/04/04
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Andreas Färber, 2012/04/05
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Blue Swirl, 2012/04/11
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, David Gibson, 2012/04/10
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code, Blue Swirl, 2012/04/11
[Qemu-ppc] [PATCH 2/3] pseries: Use more conventional PCI interrupt swizzling, David Gibson, 2012/04/02
Re: [Qemu-ppc] [PATCH 1/3] pseries: Fix RTAS based config access, Andreas Färber, 2012/04/12
Re: [Qemu-ppc] [PATCH 1/3] pseries: Fix RTAS based config access, Michael S. Tsirkin, 2012/04/15