qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: david@gibson.dropbear.id.au, aik@ozlabs.ru, dwmw2@infradead.org
Cc: kvm@vger.kernel.org, iommu@lists.linux-foundation.org,
	qemu-devel@nongnu.org, alex.williamson@redhat.com,
	joerg.roedel@amd.com, linux-kernel@vger.kernel.org
Subject: [Qemu-devel] [PATCH 0/2] RFC Isolation API
Date: Mon, 12 Mar 2012 16:32:46 -0600	[thread overview]
Message-ID: <20120312220109.30321.83419.stgit@bling.home> (raw)

VFIO is completely stalled waiting on a poorly defined device isolation
infrastructure to take shape.  Rather than waiting any longer, I've
decided to write my own.  This is nowhere near ready for upstream, but
attempts to hash out some of the interactions of isolation groups.

To recap, an isolation group is a set of devices, between which there
is no guaranteed isolation.  Between isolation groups, we do have
isolation, generally provided by an IOMMU.  On x86 systems with either
VT-d or AMD-Vi, we often have function level isolation (assuming you
trust the device).  Hardware topologies such as PCIe-to-PCI bridges
can decrease this granularity.  PowerPC systems often set the delimiter
at the PCI bridge level and refer to these as Partitionable Endpoints.

VFIO is a userspace driver interface tailored as a replacement for
KVM device assignment.  In order to provide secure userspace driver
interfaces, we must first ensure that we have an isolated device
infrastructure.  This attempts to define the basics of such an
interface.

In addition to isolation groups, this series also introduces the idea
of an isolation "provider".  This is simply a driver which defines
isolation groups, for example intel-iommu.  This interface supports
multiple providers simultaneously.  We also have the idea of a "manager"
for an isolation group.  When a manager is set for an isolation group,
it changes the way driver matching works for devices.  We only allow
matching to drivers registered by the isolation group manager.  Once all
of the devices in an isolation group are bound to manager registered
drivers (or no driver), the group is "locked" under manager control.

This proposal is far from complete, but I hope it can re-fire some
discussion and work in this space.  Please let me know what you like,
what you don't like, and ideas for the gaps.  Thanks,

Alex

---

Alex Williamson (2):
      intel-iommu: Basic isolation group provider support
      Isolation groups


 drivers/base/Kconfig        |   10 +
 drivers/base/Makefile       |    1 
 drivers/base/base.h         |    5 
 drivers/base/isolation.c    |  798 +++++++++++++++++++++++++++++++++++++++++++
 drivers/iommu/intel-iommu.c |   70 ++++
 include/linux/device.h      |    4 
 include/linux/isolation.h   |  138 +++++++
 7 files changed, 1026 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/isolation.c
 create mode 100644 include/linux/isolation.h

             reply	other threads:[~2012-03-12 22:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-12 22:32 Alex Williamson [this message]
2012-03-12 22:32 ` [Qemu-devel] [PATCH 1/2] Isolation groups Alex Williamson
2012-03-13 14:33   ` David Gibson
2012-03-13 16:49     ` Alex Williamson
2012-03-14  9:58       ` David Gibson
2012-03-15 20:15         ` Alex Williamson
2012-03-16  3:45           ` David Gibson
2012-03-16 19:31             ` Alex Williamson
2012-03-17  4:57               ` David Gibson
2012-03-21 21:12                 ` Alex Williamson
2012-03-27  5:14                   ` David Gibson
2012-03-27 19:34                     ` Alex Williamson
2012-03-30  4:19                       ` David Gibson
2012-03-12 22:33 ` [Qemu-devel] [PATCH 2/2] intel-iommu: Basic isolation group provider support Alex Williamson
2012-03-13 13:57 ` [Qemu-devel] [PATCH 0/2] RFC Isolation API 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=20120312220109.30321.83419.stgit@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).