From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org"
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
"Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
<Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org"
<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [GIT PULL] iommu: Kill off pgsize_bitmap field from struct iommu_ops
Date: Tue, 31 Mar 2015 15:49:56 +0100 [thread overview]
Message-ID: <20150331144956.GA24094@arm.com> (raw)
In-Reply-To: <20150331142440.GD22683-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On Tue, Mar 31, 2015 at 03:24:40PM +0100, Joerg Roedel wrote:
> Hi Will,
Hi Joerg,
> On Fri, Mar 27, 2015 at 05:19:46PM +0000, Will Deacon wrote:
> > Please can you pull the following IOMMU changes for 4.1? They move the
> > per-iommu_ops pgsize_bitmap field into the iommu_domain, which allows
> > IOMMUs such as the ARM SMMU to support different page sizes within a
> > given SoC.
>
> I have some concerns about the direction taken with this patch-set. The
> goal for the IOMMU-API is still to have domains that can be attached to
> arbitrary devices (even when mappings already exist). But with this
> patch-set we move into a direction where a domain can only be used on
> IOMMUs that support the page-sizes required by the domain. In the end
> this would be visible to the user of the IOMMU-API, which is not what we
> want.
But isn't this restriction already the case in practice? For example, if
I have a domain with some mapping already configured, then that mapping
will be using some fixed set of page sizes. Attaching a device behind
another IOMMU that doesn't support that page size would effectively require
the domain page tables to be freed and re-allocated from scratch.
So I don't think this patch series leaves us any worse off that we currently
are already.
Ths plus points of the patches are that:
- We can support different page sizes per domain (the ARM SMMU hardware
really does support this and it would be nice to exploit that to gain
better TLB utilisation)
- We can support systems containing IOMMUs that don't support a common
page size (I believe the arm64 Juno platform has this feature)
- I don't have to manipulate a const data structure (iommu_ops) at runtime
whenever I find a new IOMMU with a different set of supported page
sizes.
> I can understand the motivation behind these patches, but we need to
> think about how this could work with the desired semantics of the
> IOMMU-API.
Do we have any code using this feature of the IOMMU API? I don't think it's
realistic in the general case to allow arbitrary devices to be attached to a
domain unless the domain can also span multiple IOMMUs. In that case, we'd
actually need multiple sets of page tables, potentially described using
different formats...
Will
next prev parent reply other threads:[~2015-03-31 14:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 17:19 [GIT PULL] iommu: Kill off pgsize_bitmap field from struct iommu_ops Will Deacon
[not found] ` <20150327171946.GL1562-5wv7dgnIgG8@public.gmane.org>
2015-03-31 14:24 ` Joerg Roedel
[not found] ` <20150331142440.GD22683-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-03-31 14:49 ` Will Deacon [this message]
[not found] ` <20150331144956.GA24094-5wv7dgnIgG8@public.gmane.org>
2015-03-31 15:50 ` Alex Williamson
[not found] ` <1427817050.5567.148.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-01 11:53 ` Will Deacon
[not found] ` <20150401115340.GG1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 15:53 ` Joerg Roedel
2015-04-01 16:45 ` Alex Williamson
2015-04-01 15:38 ` Joerg Roedel
[not found] ` <20150401153854.GG4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-04-01 17:03 ` Will Deacon
[not found] ` <20150401170330.GO1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 21:24 ` Joerg Roedel
2015-03-31 16:07 ` Robin Murphy
2015-04-01 13:14 ` David Woodhouse
[not found] ` <1427894051.22236.6.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 13:39 ` Will Deacon
[not found] ` <20150401133908.GI1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 13:52 ` David Woodhouse
[not found] ` <1427896377.22236.8.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 14:05 ` Will Deacon
[not found] ` <20150401140512.GJ1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 14:28 ` David Woodhouse
[not found] ` <1427898490.22236.10.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 14:39 ` Will Deacon
[not found] ` <20150401143904.GL1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 14:46 ` David Woodhouse
[not found] ` <1427899570.22236.14.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 16:36 ` Will Deacon
[not found] ` <20150401163618.GN1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 21:28 ` joro-zLv9SwRftAIdnm+yROfE0A
[not found] ` <20150401212854.GK4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-04-02 8:58 ` Will Deacon
2015-04-01 16:51 ` Alex Williamson
[not found] ` <1427907064.5567.256.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-01 17:50 ` Will Deacon
[not found] ` <20150401175040.GQ1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 18:18 ` Alex Williamson
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=20150331144956.GA24094@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox