linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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 23:24:40 +0200	[thread overview]
Message-ID: <20150401212440.GJ4441@8bytes.org> (raw)
In-Reply-To: <20150401170330.GO1552@arm.com>

Hi Will,

On Wed, Apr 01, 2015 at 06:03:30PM +0100, Will Deacon wrote:
> Agreed. How would you feel about restricting domains to be per-IOMMU
> instance?

If we find a good way to do that it would be fine. We need to expose
information about individual IOMMUs for that. The question is whether we
need to expose them to the IOMMU-API user or just from the drivers to
the IOMMU core code.

I prefer the second option, but if there is a good and clean way for the
first one I am open for discussions.

> VFIO already copes with this, so I think we'd just need something to
> keep legacy KVM device passthrough working on x86.

VFIO uses a lot of implicit and internal knowledge about the backend
IOMMU drivers to decide if a second domain is needed. I think this logic
should either be moved into the iommu core code or made generic enough
that it works not only for different supported page-size, but also for
snooping flags or whatever differences exist between iommus in a system.

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

The legacy device assignment code can also be adapted to whatever
changes we agree upon, no need to support a stable API in the iommu
code.


	Joerg

  reply	other threads:[~2015-04-01 21:24 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
2015-04-01 21:24         ` Joerg Roedel [this message]
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=20150401212440.GJ4441@8bytes.org \
    --to=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).