From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Mon, 27 Apr 2015 18:04:23 +0100 Subject: [PATCH 1/2] irqchip/gicv3-its: Support share device ID In-Reply-To: References: <20150422170718.GG13019@arm.com> <20150424161818.GC7313@arm.com> <553A72D4.7000801@arm.com> <20150425113930.7386a42a@arm.com> <553DEC20.3010400@arm.com> Message-ID: <20150427170423.GC3310@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. Will