[V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
marc.zyngier at arm.com
Thu Nov 6 08:34:09 PST 2014
On 06/11/14 10:42, Thomas Gleixner wrote:
> On Thu, 6 Nov 2014, Thomas Gleixner wrote:
>> On Wed, 5 Nov 2014, Suravee Suthikulanit wrote:
>>> On 11/5/2014 6:05 PM, Suravee Suthikulanit wrote:
>>>> - Overall, it seems that msi_domain_alloc() could be quite different
>>>> across architectures. Would it be possible to declare this function as
>>>> weak, and allow arch to override (similar to arch_setup_msi_irq)?
>>> Actually, declaring "msi_domain_ops" as non-static, and allow other code to
>>> override the .alloc and .free?
>> Why do you want to do that?
> I know why. Because you want to spare a level of hierarchy. But thats
> wrong simply because MSI itself is an interrupt chip at the device
> [ MSI ] ---> [ GIC-MSI ] ---> [ GIC ]
> So the MSI level only cares about the allocation of the virq
> space. GIC-MSI allocates out of the bitmap which handles the hard
> wired range of MSI capable GIC interrupts and GIC handles the
> underlying functionality.
> And this makes a lot of sense, if you think about interrupt
> remapping. If ARM ever grows that you simply insert it into the chain:
> [ MSI ] ---> [ Remap] ---> [ GIC-MSI ] ---> [ GIC ]
I think ARM has reached that stage with the ITS block in GICv3:
- Each device gets programmed with a set of "event IDs" ranging from 0
to N-1, with N being the number of MSI vectors used by the device
- the ITS uses both the device ID (basically the PCI requester ID) and
the event ID to parse a set of software-managed tables (think page
tables for interrupts).
The x86 remapping thing looks quite similar to that, by reading a couple
of pages from the VT-D document.
So the way I understand the layout (and please correct me if I'm wrong,
which is certainly the case) is that the MSI domain is entirely generic,
allocates the virq, uses Remap as a parent, and uses
irq_chip_compose_msi_msg to call into the parent and generate whatever
goes into the MSI message.
I'm still struggling a bit to see how the remapping layer can access the
requester ID. x86 uses the irq_alloc_info to store that (the result of
an msi_get_hwirq call), but we don't have an equivalent structure on
I'll try to hack something with my current ITS driver and come back with
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel