All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 1 Apr 2015 18:03:30 +0100	[thread overview]
Message-ID: <20150401170330.GO1552@arm.com> (raw)
In-Reply-To: <20150401153854.GG4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.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

WARNING: multiple messages have this Message-ID (diff)
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

  parent reply	other threads:[~2015-04-01 17:03 UTC|newest]

Thread overview: 48+ 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-27 17:19 ` Will Deacon
     [not found] ` <20150327171946.GL1562-5wv7dgnIgG8@public.gmane.org>
2015-03-31 14:24   ` Joerg Roedel
2015-03-31 14:24     ` Joerg Roedel
     [not found]     ` <20150331142440.GD22683-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-03-31 14:49       ` Will Deacon
2015-03-31 14:49         ` Will Deacon
     [not found]         ` <20150331144956.GA24094-5wv7dgnIgG8@public.gmane.org>
2015-03-31 15:50           ` Alex Williamson
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
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 15:53                     ` Joerg Roedel
2015-04-01 16:45                   ` Alex Williamson
2015-04-01 16:45                     ` Alex Williamson
2015-04-01 15:38           ` Joerg Roedel
2015-04-01 15:38             ` Joerg Roedel
     [not found]             ` <20150401153854.GG4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-04-01 17:03               ` Will Deacon [this message]
2015-04-01 17:03                 ` Will Deacon
     [not found]                 ` <20150401170330.GO1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 21:24                   ` Joerg Roedel
2015-04-01 21:24                     ` Joerg Roedel
2015-03-31 16:07       ` Robin Murphy
2015-03-31 16:07         ` Robin Murphy
2015-04-01 13:14   ` David Woodhouse
2015-04-01 13:14     ` David Woodhouse
     [not found]     ` <1427894051.22236.6.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 13:39       ` Will Deacon
2015-04-01 13:39         ` Will Deacon
     [not found]         ` <20150401133908.GI1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 13:52           ` David Woodhouse
2015-04-01 13:52             ` David Woodhouse
     [not found]             ` <1427896377.22236.8.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 14:05               ` Will Deacon
2015-04-01 14:05                 ` Will Deacon
     [not found]                 ` <20150401140512.GJ1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 14:28                   ` David Woodhouse
2015-04-01 14:28                     ` David Woodhouse
     [not found]                     ` <1427898490.22236.10.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 14:39                       ` Will Deacon
2015-04-01 14:39                         ` Will Deacon
     [not found]                         ` <20150401143904.GL1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 14:46                           ` David Woodhouse
2015-04-01 14:46                             ` David Woodhouse
     [not found]                             ` <1427899570.22236.14.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-01 16:36                               ` Will Deacon
2015-04-01 16:36                                 ` Will Deacon
     [not found]                                 ` <20150401163618.GN1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 21:28                                   ` joro-zLv9SwRftAIdnm+yROfE0A
2015-04-01 21:28                                     ` joro at 8bytes.org
     [not found]                                     ` <20150401212854.GK4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-04-02  8:58                                       ` Will Deacon
2015-04-02  8:58                                         ` Will Deacon
2015-04-01 16:51               ` Alex Williamson
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
2015-04-01 17:50                     ` Will Deacon
     [not found]                     ` <20150401175040.GQ1552-5wv7dgnIgG8@public.gmane.org>
2015-04-01 18:18                       ` Alex Williamson
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-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 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.