[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 02/35] ppc/xive: add support for the LSI inte
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v3 02/35] ppc/xive: add support for the LSI interrupt sources |
Date: |
Sat, 5 May 2018 14:32:48 +1000 |
User-agent: |
Mutt/1.9.3 (2018-01-21) |
On Fri, May 04, 2018 at 04:25:16PM +0200, Cédric Le Goater wrote:
> On 04/27/2018 04:43 AM, David Gibson wrote:
> >>>> I did some work on that topic a while ago :
> >>>>
> >>>> https://patchwork.ozlabs.org/cover/836782/
> >>>>
> >>>> But we stopped exploring the idea. May be it was not the good approach.
> >>>> The PHBs LSIs would benefit from such a split though.
> >>> So, no, I don't think that was a good approach, but that doesn't mean
> >>> other ways of rearranging the irq numbers aren't ok. The thing here
> >>> is that we don't want to think of an "irq allocator" - there are some
> >>> bits like that in there already, but they were always a mistake.
> >>>
> >>> We have lots of irq space (both XICS and XIVE) so instead we should
> >>> come up with a static mapping of irqs to devices.
> >> yes. I would prefer that also.
> >>
> >> We could change the spapr_irq_alloc() routine to get a block of
> >> IRQs in the range defined for a device family, and use a device
> >> id to offset in that family range ? Here are some figures :
> >>
> >> device family block size max devices
> >>
> >> EVENT_CLASS_EPOW 1 1
> >> EVENT_CLASS_HOT_PLUG 1 1
> >> VIO_VSCSI 1 10
> >> VIO_LLAN 1 10
> >> VIO_VTY 1 5
> >>
> >> PCI/PHB 1024 5
> > No, I'm thinking we should eliminate spapr_irq_alloc() entirely.
> > Well, ok, not entirely, we'll still need it for the old machine
> > types. But remove it's use for the current machine type completely.
> >
> > Instead we have an explicit map of ranges for various purposes. The
> > one-off things like EPOW and HOTPLUG can have plain constant values.
> > PCI LSIs will be calculated as something like PCI_IRQ_BASE + <phb
> > index>*4 + <irq pin>. The VIO devices we handle as VIO_BASE + <reg
> > value> or something.
> >
> > MSIs will still need some sort of allocation, but we can do that
> > within a range set aside for them.
>
> Should we address the static mapping of irqs before introducing XIVE ?
Yes, I think so.
> I don't think it changes much of the architecture now that the allocator
> is under the machine. However, I wonder what would be the impact of
> PHB hotplug.
I don't think it should be too bad. We now require that PHBs have the
'index' parameter set, and that won't change with hotplug. We can
then set aside a region of irq #s for each index of PHB.
--
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
signature.asc
Description: PGP signature