> -----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? Stuart -- 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
