Re: kvm PCI assignment & VFIO ramblings

On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:

On 25.08.2011, at 07:31, Roedel, Joerg wrote:

quoted

On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:

quoted

On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:

[...]

quoted

quoted

We need to try the polite method of attempting to hot unplug the device
from qemu first, which the current vfio code already implements.  We can
then escalate if it doesn't respond.  The current code calls abort in
qemu if the guest doesn't respond, but I agree we should also be
enforcing this at the kernel interface.  I think the problem with the
hard-unplug is that we don't have a good revoke mechanism for the mmio
mmaps.

For mmio we could stop the guest and replace the mmio region with a
region that is filled with 0xff, no?

Sure, but that happens in user space. The question is how does
kernel space enforce an MMIO region to not be mapped after the
hotplug event occured? Keep in mind that user space is pretty much
untrusted here - it doesn't have to be QEMU. It could just as well
be a generic user space driver. And that can just ignore hotplug
events.

We're saying you hard yank the mapping from the userspace process.
That is, you invalidate all its PTEs mapping the MMIO space, and don't
let it fault them back in.

As I see it there are two options: (a) make subsequent accesses from
userspace or the guest result in either a SIGBUS that userspace must
either deal with or die, or (b) replace the mapping with a dummy RO
mapping containing 0xff, with any trapped writes emulated as nops.

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