linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: dwmw2@infradead.org, iommu@lists.linux-foundation.org,
	aik@ozlabs.ru, benh@kernel.crashing.org, qemu-devel@nongnu.org,
	joerg.roedel@amd.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: Device isolation groups
Date: Fri, 9 Mar 2012 14:40:02 +1100	[thread overview]
Message-ID: <20120309034002.GP10735@truffala.fritz.box> (raw)
In-Reply-To: <1330543855.29701.180.camel@bling.home>

On Wed, Feb 29, 2012 at 12:30:55PM -0700, Alex Williamson wrote:
> On Thu, 2012-02-02 at 12:24 +1100, David Gibson wrote:
> > On Wed, Feb 01, 2012 at 01:08:39PM -0700, Alex Williamson wrote:
[snip]
> Any update to this series?  It would be great if we could map out the
> functionality to the point of breaking down and distributing work... or
> determining if the end result has any value add to what VFIO already
> does.  Thanks,

Yes and no.

No real change on the isolation code per se.  I had been hoping for
feedback from David Woodhouse, but I guess he's been too busy.

In the meantime, however, Alexey has been working on a different
approach to doing PCI passthrough which is more suitable for our
machines.  It is based on passing through an entire virtual host
bridge (which could be a whole host side host bridge, or a subset,
depending on host isolation capabilities), rather than individual
devices.  This makes it substantially simpler than VFIO (we don't need
to virtualize config space or device addresses), and it provides
better enforcement of isolation guarantees (VFIO isolation can be
broken if devices have MMIO backdoors to config space, or if they can
be made to DMA to other devices MMIO addresses instead of RAM
addresses), but does require suitable bridge hardware - pSeries has
such hardware, x86 mostly doesn't (although it wouldn't surprise me if
large server class x86 machines do or will provide the necessary
things).  Even on this sort of hardware the device-centred VFIO
approach may have uses, since it might allow finer grained division,
at the cost of isolation enforcement.

This provides a more concrete case for the isolation infrastructure,
since it would allow the virtual-PHB and VFIO approaches to co-exist.
As Alexey's prototype comes into shape, it should illuminate what
other content we need in the isolation infrastructure to make it fully
usable.

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

      reply	other threads:[~2012-03-09  3:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01  4:46 RFC: Device isolation groups David Gibson
2012-02-01  4:46 ` [PATCH 1/3] Device isolation group infrastructure (v3) David Gibson
2012-02-08 15:27   ` Joerg Roedel
2012-02-08 21:39     ` Benjamin Herrenschmidt
2012-02-09 11:28       ` Joerg Roedel
2012-02-10  0:21         ` David Gibson
2012-02-08 21:43     ` Benjamin Herrenschmidt
2012-02-09  1:40     ` David Gibson
2012-02-01  4:46 ` [PATCH 2/3] device_isolation: Support isolation on POWER p5ioc2 bridges David Gibson
2012-02-01 18:58   ` Alex Williamson
2012-02-01 19:15     ` Alex Williamson
2012-02-01  4:46 ` [PATCH 3/3] device_isolation: Support isolation on POWER p7ioc (IODA) bridges David Gibson
2012-02-01 19:17   ` Alex Williamson
2012-02-02  0:23     ` David Gibson
2012-02-01 20:08 ` RFC: Device isolation groups Alex Williamson
2012-02-02  1:24   ` David Gibson
2012-02-29 19:30     ` Alex Williamson
2012-03-09  3:40       ` David Gibson [this message]

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=20120309034002.GP10735@truffala.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=benh@kernel.crashing.org \
    --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).