From: Alex Williamson <alex.williamson@redhat.com>
To: David Gibson <dwg@au1.ibm.com>
Cc: joerg.roedel@amd.com, dwmw2@infradead.org,
iommu@lists.linux-foundation.org, aik@au1.ibm.com,
linux-kernel@vger.kernel.org, chrisw@redhat.com, agraf@suse.de,
scottwood@freescale.com, B08248@freescale.com,
benh@kernel.crashing.org
Subject: Re: RFC: Device isolation infrastructure
Date: Wed, 07 Dec 2011 23:23:10 -0700 [thread overview]
Message-ID: <1323325390.24340.81.camel@bling.home> (raw)
In-Reply-To: <20111208024357.GB5344@truffala.fritz.box>
On Thu, 2011-12-08 at 13:43 +1100, David Gibson wrote:
> On Wed, Dec 07, 2011 at 12:45:20PM -0700, Alex Williamson wrote:
> > So the next problem is that while the group is the minimum granularity
> > for the iommu, it's not necessarily the desired granularity. iommus
> > like VT-d have per PCI BDF context entries that can point to shared page
> > tables. On such systems we also typically have singleton isolation
> > groups, so when multiple devices are used by a single user, we have a
> > lot of duplication in time and space. VFIO handles this by allowing
> > groups to be "merged". When this happens, the merged groups point to
> > the same iommu context. I'm not sure what the plan is with isolation
> > groups, but we need some way to reduce that overhead.
>
> Right. So, again, I intend that mutiple groups can go into one
> domain. Not entirely sure of the interface yet. One I had in mind
> was to borrow the vfio1 interface, so you open a /dev/vfio (each open
> gives a new instance). Then you do an "addgroup" ioctl which adds a
> group to the domain. You can do that multiple times, then start using
> the domain.
This also revisits one of the primary problems of vfio1, the dependency
on a privileged uiommu domain creation interface. Assigning a user
ownership of a group should be a privileged operation. If a privileged
user needs to open /dev/vfio, add groups, then drop privileges and hand
the open file descriptor to an unprivileged user, the interface becomes
much harder to use. "Hot merging" becomes impossible.
Alex
next prev parent reply other threads:[~2011-12-08 6:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 3:58 RFC: Device isolation infrastructure David Gibson
2011-12-07 6:22 ` Benjamin Herrenschmidt
2011-12-07 6:46 ` Alex Williamson
2011-12-07 14:22 ` David Gibson
2011-12-07 19:45 ` Alex Williamson
2011-12-07 23:41 ` Benjamin Herrenschmidt
2011-12-08 0:16 ` Chris Wright
2011-12-08 1:32 ` Benjamin Herrenschmidt
2011-12-08 1:36 ` Chris Wright
2011-12-08 5:51 ` Alex Williamson
2011-12-09 2:38 ` David Gibson
2011-12-08 2:43 ` David Gibson
2011-12-08 6:23 ` Alex Williamson [this message]
2011-12-08 6:52 ` David Gibson
2011-12-08 14:28 ` Alex Williamson
2011-12-09 3:00 ` David Gibson
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=1323325390.24340.81.camel@bling.home \
--to=alex.williamson@redhat.com \
--cc=B08248@freescale.com \
--cc=agraf@suse.de \
--cc=aik@au1.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=chrisw@redhat.com \
--cc=dwg@au1.ibm.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=scottwood@freescale.com \
/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