All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Alexandre Courbot
	<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"jroedel-l3A5Bk7waGM@public.gmane.org"
	<jroedel-l3A5Bk7waGM@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 02/15] iommu: Introduce iommu domain types
Date: Fri, 30 Jan 2015 13:22:34 +0100	[thread overview]
Message-ID: <20150130122233.GA3702@8bytes.org> (raw)
In-Reply-To: <20150128141934.GP1569-5wv7dgnIgG8@public.gmane.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

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>, Kukjin Kim <kgene@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Heiko Stuebner <heiko@sntech.de>, Hiroshi Doyu <hdoyu@nvidia.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>,
	"linux-rockchip@lists.infradead.org" 
	<linux-rockchip@lists.infradead.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"jroedel@suse.de" <jroedel@suse.de>
Subject: Re: [PATCH 02/15] iommu: Introduce iommu domain types
Date: Fri, 30 Jan 2015 13:22:34 +0100	[thread overview]
Message-ID: <20150130122233.GA3702@8bytes.org> (raw)
In-Reply-To: <20150128141934.GP1569@arm.com>

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


WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/15] iommu: Introduce iommu domain types
Date: Fri, 30 Jan 2015 13:22:34 +0100	[thread overview]
Message-ID: <20150130122233.GA3702@8bytes.org> (raw)
In-Reply-To: <20150128141934.GP1569@arm.com>

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

  parent reply	other threads:[~2015-01-30 12:22 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26 23:51 [PATCH 00/15] iommu: Move domain allocation into drivers Joerg Roedel
2015-01-26 23:51 ` Joerg Roedel
2015-01-26 23:51 ` Joerg Roedel
     [not found] ` <1422316305-19216-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-01-26 23:51   ` [PATCH 01/15] iommu: Introduce domain_alloc and domain_free iommu_ops Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 02/15] iommu: Introduce iommu domain types Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
     [not found]     ` <1422316305-19216-3-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-01-28 14:19       ` Will Deacon
2015-01-28 14:19         ` Will Deacon
2015-01-28 14:19         ` Will Deacon
     [not found]         ` <20150128141934.GP1569-5wv7dgnIgG8@public.gmane.org>
2015-01-30 12:22           ` Joerg Roedel [this message]
2015-01-30 12:22             ` Joerg Roedel
2015-01-30 12:22             ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 03/15] iommu/amd: Make use of domain_alloc and domain_free Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 04/15] iommu/vt-d: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 05/15] iommu/omap: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 06/15] iommu/arm-smmu: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 07/15] iommu/exynos: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 08/15] iommu/tegra-smmu: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 09/15] iommu/tegra-gart: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 10/15] iommu/msm: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 11/15] iommu/shmobile: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 12/15] iommu/ipmmu-vmsa: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 13/15] iommu/rockchip: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 14/15] iommu/fsl: " Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51   ` [PATCH 15/15] iommu: Remove domain_init and domain_free iommu_ops Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-01-26 23:51     ` Joerg Roedel
2015-03-20  9:24 ` [PATCH 00/15] iommu: Move domain allocation into drivers Yingjoe Chen
2015-03-20  9:24   ` Yingjoe Chen
2015-03-23 11:49   ` Joerg Roedel
2015-03-23 11:49     ` Joerg Roedel
2015-03-23 11:49     ` Joerg Roedel
     [not found]     ` <20150323114921.GM4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-03-23 13:35       ` Yingjoe Chen
2015-03-23 13:35         ` Yingjoe Chen
2015-03-23 13:35         ` Yingjoe Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150130122233.GA3702@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jroedel-l3A5Bk7waGM@public.gmane.org \
    --cc=kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.