[PATCH 1/2] irqchip/gicv3-its: Support share device ID

Will Deacon will.deacon at arm.com
Fri May 1 08:26:52 PDT 2015


On Fri, May 01, 2015 at 04:23:31PM +0100, Stuart Yoder wrote:
> 
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon at arm.com]
> > Sent: Monday, April 27, 2015 12:04 PM
> > To: Sethi Varun-B16395
> > Cc: Marc Zyngier; Yoder Stuart-B08248; Lian Minghuan-B31939; linux-pci at vger.kernel.org; Arnd Bergmann; Hu
> > Mingkai-B21284; Zang Roy-R61911; Bjorn Helgaas; Wood Scott-B07421; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH 1/2] irqchip/gicv3-its: Support share device ID
> > 
> > On Mon, Apr 27, 2015 at 02:08:10PM +0100, Varun Sethi wrote:
> > > > >>> In the SMMU/GIC-500-ITS world the iommu isolation ID (the stream ID)
> > > > >>> and the GIC-ITS device ID are in fact the same ID.
> > > > >>
> > > > >> The DeviceID is the "MSI group" you mention. This is what provides
> > > > >> isolation at the ITS level.
> > > > >>
> > > > > [varun] True, in case of a transparent host bridge device Id won't
> > > > > provide the necessary isolation.
> > > >
> > > > Well, it depends how you look at it. How necessary is this isolation, since
> > > > we've already established that you couldn't distinguish between these
> > > > devices at the IOMMU level?
> > > >
> > > [varun] Yes, the devices would fall in the same IOMMU group. So, devices
> > > would end up sharing the interrupt?
> > 
> > Well, I think that's the crux of the issue here. If IOMMU groups are also
> > needed to relay constraints to the IRQ subsystem, then perhaps we need a
> > more general notion of device grouping and ID transformations between
> > the different levels of group hierarchy.
> 
> I agree.  Have been thinking about it over the last few days...is is
> a matter of renaming what we currently call an "IOMMU group"?   Or,
> do we really need to separate general 'device grouping' and 'iommu groups'
> in the Linux kernel?

It depends. Right now, the IOMMU drivers are responsible for creating the
IOMMU groups and I don't think that's general enough for what we need in
practice. If we move the group creation to be done as part of the bus, then
that would be the first step in having an abstraction that could be re-used
by the interrupt code imo. It would also move us a step closer to having
a generic device group description for platform-bus devices (i.e. as part
of the devicetree).

I suspect the only way we'll really find out is by prototyping stuff and
sending patches.

Will



More information about the linux-arm-kernel mailing list