From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:57244 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753218AbbD0RE1 (ORCPT ); Mon, 27 Apr 2015 13:04:27 -0400 Date: Mon, 27 Apr 2015 18:04:23 +0100 From: Will Deacon To: Varun Sethi Cc: Marc Zyngier , Stuart Yoder , "Minghuan.Lian@freescale.com" , "linux-pci@vger.kernel.org" , Arnd Bergmann , "Mingkai.Hu@freescale.com" , Roy Zang , Bjorn Helgaas , Scott Wood , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 1/2] irqchip/gicv3-its: Support share device ID Message-ID: <20150427170423.GC3310@arm.com> References: <20150422170718.GG13019@arm.com> <20150424161818.GC7313@arm.com> <553A72D4.7000801@arm.com> <20150425113930.7386a42a@arm.com> <553DEC20.3010400@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-pci-owner@vger.kernel.org List-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. Will 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