From: David Gibson <dwg@au1.ibm.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Aaron Fabbri (aafabbri)" <aafabbri@cisco.com>,
aik@au1.ibm.com, kvm@vger.kernel.org, pmac@au1.ibm.com,
joerg.roedel@amd.com, konrad.wilk@oracle.com, agraf@suse.de,
qemu-devel@nongnu.org, chrisw@sous-sol.org, B08248@freescale.com,
iommu@lists.linux-foundation.org, avi@redhat.com,
linux-pci@vger.kernel.org, B07421@freescale.com,
"Christian Benvenuti (benve)" <benve@cisco.com>
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
Date: Tue, 15 Nov 2011 11:05:05 +1100 [thread overview]
Message-ID: <20111115000505.GA5035@truffala.fritz.box> (raw)
In-Reply-To: <1321311540.17169.122.camel@bling.home>
On Mon, Nov 14, 2011 at 03:59:00PM -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 16:22 -0600, Christian Benvenuti (benve) wrote:
[snip]
> > - the user either unmaps one specific mapping or 'all of them'.
> > The 'all of them' case would also take care of those cases where
> > the user does _not_ keep track of mappings and simply uses
> > the "unmap from 0 to ~0" each time.
> >
> > Because of this you could still provide an exact map/unmap logic
> > and allow such "unmap from 0 to ~0" by making the latter a special
> > case.
> > However, if we want to allow any arbitrary/inexact unmap request, then OK.
>
> I can't think of any good reasons we shouldn't be more strict. I think
> it was primarily just convenient to hit all the corner cases since we
> merge all the requests together for tracking and need to be able to
> split them back apart. It does feel a little awkward to have a 0/~0
> special case though, but I don't think it's worth adding another ioctl
> to handle it.
Being strict, or at least enforcing strictness, requires that the
infrastructure track all the maps, so that the unmaps can be
matching. This is not a natural thing with the data structures you
want for all IOMMUs. For example on POWER, the IOMMU (aka TCE table)
is a simple 1-level pagetable. One pointer with a couple of
permission bits per IOMMU page. Handling oddly overlapping operations
on that data structure is natural, enforcing strict matching of maps
and unmaps is not and would require extra information to be stored by
vfio. On POWER, the IOMMU operations often *are* a hot path, so
manipulating those structures would have a real cost, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2011-11-15 0:13 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 20:12 [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework Alex Williamson
2011-11-09 4:17 ` Aaron Fabbri
2011-11-09 4:41 ` Alex Williamson
2011-11-09 8:11 ` Christian Benvenuti (benve)
2011-11-09 18:02 ` Alex Williamson
2011-11-09 21:08 ` Christian Benvenuti (benve)
2011-11-09 23:40 ` Alex Williamson
2011-11-10 0:57 ` Christian Benvenuti (benve)
2011-11-11 18:04 ` Alex Williamson
2011-11-11 22:22 ` Christian Benvenuti (benve)
2011-11-14 22:59 ` Alex Williamson
2011-11-15 0:05 ` David Gibson [this message]
2011-11-15 0:49 ` Benjamin Herrenschmidt
2011-11-11 17:51 ` Konrad Rzeszutek Wilk
2011-11-11 22:10 ` Alex Williamson
2011-11-15 0:00 ` David Gibson
2011-11-16 16:52 ` Konrad Rzeszutek Wilk
2011-11-17 20:22 ` Alex Williamson
2011-11-17 20:56 ` Scott Wood
2011-11-16 17:47 ` Scott Wood
2011-11-17 20:52 ` Alex Williamson
2011-11-12 0:14 ` Scott Wood
2011-11-14 20:54 ` Alex Williamson
2011-11-14 21:46 ` Alex Williamson
2011-11-14 22:26 ` Scott Wood
2011-11-14 22:48 ` Alexander Graf
2011-11-15 2:29 ` Alex Williamson
2011-11-15 6:34 ` David Gibson
2011-11-15 18:01 ` Alex Williamson
2011-11-17 0:02 ` David Gibson
2011-11-18 20:32 ` Alex Williamson
2011-11-18 21:09 ` Scott Wood
2011-11-22 19:16 ` Alex Williamson
2011-11-22 20:00 ` Scott Wood
2011-11-22 21:28 ` Alex Williamson
2011-11-21 2:47 ` David Gibson
2011-11-22 18:22 ` Alex Williamson
2011-11-15 20:10 ` Scott Wood
2011-11-15 21:40 ` Aaron Fabbri
2011-11-15 22:29 ` Scott Wood
2011-11-16 23:34 ` Alex Williamson
2011-11-29 1:52 ` Alexey Kardashevskiy
2011-11-29 2:01 ` Alexey Kardashevskiy
2011-11-29 2:11 ` Alexey Kardashevskiy
2011-11-29 3:54 ` Alex Williamson
2011-11-29 19:26 ` Alex Williamson
2011-11-29 23:20 ` Stuart Yoder
2011-11-29 23:44 ` Alex Williamson
2011-11-30 15:41 ` Stuart Yoder
2011-11-30 16:58 ` Alex Williamson
2011-12-01 20:58 ` Stuart Yoder
2011-12-01 21:25 ` Alex Williamson
2011-12-02 14:40 ` Stuart Yoder
2011-12-02 18:11 ` Bhushan Bharat-R65777
2011-12-02 18:27 ` Scott Wood
2011-12-02 18:35 ` Bhushan Bharat-R65777
2011-12-02 18:45 ` Bhushan Bharat-R65777
2011-12-02 18:52 ` Scott Wood
2011-12-02 18:21 ` Scott Wood
2011-11-29 3:46 ` Alex Williamson
2011-11-29 4:34 ` Alexey Kardashevskiy
2011-11-29 5:48 ` Alex Williamson
2011-12-02 5:06 ` Alexey Kardashevskiy
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=20111115000505.GA5035@truffala.fritz.box \
--to=dwg@au1.ibm.com \
--cc=B07421@freescale.com \
--cc=B08248@freescale.com \
--cc=aafabbri@cisco.com \
--cc=agraf@suse.de \
--cc=aik@au1.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=benve@cisco.com \
--cc=chrisw@sous-sol.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=pmac@au1.ibm.com \
--cc=qemu-devel@nongnu.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).