On Fri, May 01, 2015 at 04:23:31PM +0100, Stuart Yoder wrote: > > > > -----Original Message----- > > From: Will Deacon [mailto:will.deacon@xxxxxxx] > > Sent: Monday, April 27, 2015 12:04 PM > > To: Sethi Varun-B16395 > > Cc: Marc Zyngier; Yoder Stuart-B08248; Lian Minghuan-B31939; linux-pci@xxxxxxxxxxxxxxx; Arnd Bergmann; Hu > > Mingkai-B21284; Zang Roy-R61911; Bjorn Helgaas; Wood Scott-B07421; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
