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