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: "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 17:38:54 +0200	[thread overview]
Message-ID: <20150401153854.GG4441@8bytes.org> (raw)
In-Reply-To: <20150331144956.GA24094-5wv7dgnIgG8@public.gmane.org>

Hi Will,

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.

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).

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.


	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
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 17:38:54 +0200	[thread overview]
Message-ID: <20150401153854.GG4441@8bytes.org> (raw)
In-Reply-To: <20150331144956.GA24094@arm.com>

Hi Will,

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.

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).

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.


	Joerg

  parent reply	other threads:[~2015-04-01 15:38 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 [this message]
2015-04-01 15:38             ` Joerg Roedel
     [not found]             ` <20150401153854.GG4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-04-01 17:03               ` Will Deacon
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=20150401153854.GG4441@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@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 \
    --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.