qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

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