From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [GIT PULL] iommu: Kill off pgsize_bitmap field from struct iommu_ops
Date: Wed, 1 Apr 2015 18:03:30 +0100 [thread overview]
Message-ID: <20150401170330.GO1552@arm.com> (raw)
In-Reply-To: <20150401153854.GG4441@8bytes.org>
On Wed, Apr 01, 2015 at 04:38:54PM +0100, Joerg Roedel wrote:
> Hi Will,
Hi Joerg,
> On Tue, Mar 31, 2015 at 03:49:56PM +0100, Will Deacon wrote:
> > 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.
>
> The problem is that this restriction depends on the IOMMU driver in use.
> From the beginning of the IOMMU-API the backend drivers have supported
> sharing a domain by multiple devices. In fact, the domain is just an
> abstraction for an address space that can be attached to devices just
> like cpu page-tables are assigned to threads of a process.
I think the domain is a useful abstraction; I just don't think it works
too well when you attach devices upstream of different IOMMUs to the same
domain. If all the devices attached to a domain share an IOMMU, everything
works nicely.
> We can discuss whether this fundamental concept of the IOMMU-API needs
> to be changed (moving into the direction this patch-set proposes). I
> could imaging removing the domain concept entirely and just have
> map/unmap functions like this:
>
> iommu_map(struct device *dev, dma_addr_t iova,
> phys_addr_t phys, size_t size)
> iommu_unmap(struct device *dev, dma_addr_t iova,
> phys_addr_t phys, size_t size)
>
> This would require some changes for the users of the IOMMU-API, but it
> shouldn't be too hard.
>
> Or we keep the desired semantics as they are now and do everything
> needed for that in the IOMMU drivers. For the arm-smmu this would mean
> exposing a common set of supported pgsizes between IOMMUs, or to build
> multiple page-tables to match the different IOMMU capabilities.
>
> I am open for disussions for either way, but I like the current
> semantics a bit more, as it allows us to share page-tables between
> devices and we can move all of the nasty code in VFIO that already
> creates multiple domains to get different page-tables into the
> IOMMU core or the drivers (were it belongs).
I agree that sharing page tables is desirable and I certainly wouldn't
suggest removing the domain abstraction.
> What I definitly don't want is a mixture of both concepts depending on
> the IOMMU driver in use. We should settle on one way and force the
> drivers to behave accordingly. We don't need a common API when every
> driver behaves differently.
Agreed. How would you feel about restricting domains to be per-IOMMU
instance? VFIO already copes with this, so I think we'd just need
something to keep legacy KVM device passthrough working on x86. Maybe we
could add a new domain type using your new series (DOMAIN_X86_KVM_LEGACY
or something) and avoid the cross-IOMMU domain checks for that.
Will
next prev parent reply other threads:[~2015-04-01 17:03 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
2015-03-31 14:24 ` Joerg Roedel
2015-03-31 14:49 ` Will Deacon
2015-03-31 15:50 ` Alex Williamson
2015-04-01 11:53 ` Will Deacon
2015-04-01 15:53 ` Joerg Roedel
2015-04-01 16:45 ` Alex Williamson
2015-04-01 15:38 ` Joerg Roedel
2015-04-01 17:03 ` Will Deacon [this message]
2015-04-01 21:24 ` Joerg Roedel
2015-03-31 16:07 ` Robin Murphy
2015-04-01 13:14 ` David Woodhouse
2015-04-01 13:39 ` Will Deacon
2015-04-01 13:52 ` David Woodhouse
2015-04-01 14:05 ` Will Deacon
2015-04-01 14:28 ` David Woodhouse
2015-04-01 14:39 ` Will Deacon
2015-04-01 14:46 ` David Woodhouse
2015-04-01 16:36 ` Will Deacon
2015-04-01 21:28 ` joro at 8bytes.org
2015-04-02 8:58 ` Will Deacon
2015-04-01 16:51 ` Alex Williamson
2015-04-01 17:50 ` Will Deacon
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=20150401170330.GO1552@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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