From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH 02/15] iommu: Introduce iommu domain types Date: Fri, 30 Jan 2015 13:22:34 +0100 Message-ID: <20150130122233.GA3702@8bytes.org> References: <1422316305-19216-1-git-send-email-joro@8bytes.org> <1422316305-19216-3-git-send-email-joro@8bytes.org> <20150128141934.GP1569@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20150128141934.GP1569-5wv7dgnIgG8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Will Deacon Cc: Alexandre Courbot , "linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Heiko Stuebner , Arnd Bergmann , Stephen Warren , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Kukjin Kim , Thierry Reding , "jroedel-l3A5Bk7waGM@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , David Woodhouse , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-tegra@vger.kernel.org Hi Will, On Wed, Jan 28, 2015 at 02:19:34PM +0000, Will Deacon wrote: > > +/* This are the possible domain-types */ > > +enum iommu_domain_type { > > + IOMMU_DOMAIN_DMA, /* Domain used for DMA-API */ > > + IOMMU_DOMAIN_IDENTITY, /* Identity mapped domain */ > > What happens if somebody calls map or unmap on an identity-mapping domain? > Can we catch that in the IOMMU core before calling the IOMMU driver? That > also implies we need something extra to parameterise the attributes for > the mapping (e.g. cacheable, read-only) and also potentially the address > range. The domain type is only used by the IOMMU drivers to do be able to enter special allocation paths (the AMD-Vi driver for example could allocate a special internal domain type for IOMMU_DOMAIN_DMA). But I think you are right, a couple of the current domain attributes we have could be moved here, turning the domain-type into a bit-field. So we could have bits for PAGING, CACHABLE, DMA_API and NESTING and build the domain types above from those bits. > > + IOMMU_DOMAIN_UNMANAGED, /* Domain mappings are managed by a third party > > + user (like KVM or VFIO) */ > > We already have the domain attributes (iommu_attr) to describe features > of a domain. Is there really a need for this extra type, or can we extend > the attribute set and allow for domain allocation with attributes? I don't think that domains attributed will become obsolete with this domain-type field. Some of the attributes should stay there for now, like all the PAMU specific stuff. But I agree, some could be moved over. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761798AbbA3MWi (ORCPT ); Fri, 30 Jan 2015 07:22:38 -0500 Received: from 8bytes.org ([81.169.241.247]:57530 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752721AbbA3MWg (ORCPT ); Fri, 30 Jan 2015 07:22:36 -0500 Date: Fri, 30 Jan 2015 13:22:34 +0100 From: Joerg Roedel To: Will Deacon Cc: "iommu@lists.linux-foundation.org" , Kukjin Kim , David Woodhouse , Heiko Stuebner , Hiroshi Doyu , Stephen Warren , Thierry Reding , Alexandre Courbot , Alex Williamson , Arnd Bergmann , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" , "linux-rockchip@lists.infradead.org" , "linux-tegra@vger.kernel.org" , "jroedel@suse.de" Subject: Re: [PATCH 02/15] iommu: Introduce iommu domain types Message-ID: <20150130122233.GA3702@8bytes.org> References: <1422316305-19216-1-git-send-email-joro@8bytes.org> <1422316305-19216-3-git-send-email-joro@8bytes.org> <20150128141934.GP1569@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150128141934.GP1569@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, On Wed, Jan 28, 2015 at 02:19:34PM +0000, Will Deacon wrote: > > +/* This are the possible domain-types */ > > +enum iommu_domain_type { > > + IOMMU_DOMAIN_DMA, /* Domain used for DMA-API */ > > + IOMMU_DOMAIN_IDENTITY, /* Identity mapped domain */ > > What happens if somebody calls map or unmap on an identity-mapping domain? > Can we catch that in the IOMMU core before calling the IOMMU driver? That > also implies we need something extra to parameterise the attributes for > the mapping (e.g. cacheable, read-only) and also potentially the address > range. The domain type is only used by the IOMMU drivers to do be able to enter special allocation paths (the AMD-Vi driver for example could allocate a special internal domain type for IOMMU_DOMAIN_DMA). But I think you are right, a couple of the current domain attributes we have could be moved here, turning the domain-type into a bit-field. So we could have bits for PAGING, CACHABLE, DMA_API and NESTING and build the domain types above from those bits. > > + IOMMU_DOMAIN_UNMANAGED, /* Domain mappings are managed by a third party > > + user (like KVM or VFIO) */ > > We already have the domain attributes (iommu_attr) to describe features > of a domain. Is there really a need for this extra type, or can we extend > the attribute set and allow for domain allocation with attributes? I don't think that domains attributed will become obsolete with this domain-type field. Some of the attributes should stay there for now, like all the PAMU specific stuff. But I agree, some could be moved over. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 From: joro@8bytes.org (Joerg Roedel) Date: Fri, 30 Jan 2015 13:22:34 +0100 Subject: [PATCH 02/15] iommu: Introduce iommu domain types In-Reply-To: <20150128141934.GP1569@arm.com> References: <1422316305-19216-1-git-send-email-joro@8bytes.org> <1422316305-19216-3-git-send-email-joro@8bytes.org> <20150128141934.GP1569@arm.com> Message-ID: <20150130122233.GA3702@8bytes.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Will, On Wed, Jan 28, 2015 at 02:19:34PM +0000, Will Deacon wrote: > > +/* This are the possible domain-types */ > > +enum iommu_domain_type { > > + IOMMU_DOMAIN_DMA, /* Domain used for DMA-API */ > > + IOMMU_DOMAIN_IDENTITY, /* Identity mapped domain */ > > What happens if somebody calls map or unmap on an identity-mapping domain? > Can we catch that in the IOMMU core before calling the IOMMU driver? That > also implies we need something extra to parameterise the attributes for > the mapping (e.g. cacheable, read-only) and also potentially the address > range. The domain type is only used by the IOMMU drivers to do be able to enter special allocation paths (the AMD-Vi driver for example could allocate a special internal domain type for IOMMU_DOMAIN_DMA). But I think you are right, a couple of the current domain attributes we have could be moved here, turning the domain-type into a bit-field. So we could have bits for PAGING, CACHABLE, DMA_API and NESTING and build the domain types above from those bits. > > + IOMMU_DOMAIN_UNMANAGED, /* Domain mappings are managed by a third party > > + user (like KVM or VFIO) */ > > We already have the domain attributes (iommu_attr) to describe features > of a domain. Is there really a need for this extra type, or can we extend > the attribute set and allow for domain allocation with attributes? I don't think that domains attributed will become obsolete with this domain-type field. Some of the attributes should stay there for now, like all the PAMU specific stuff. But I agree, some could be moved over. Joerg