[libvirt] [RFC PATCH] hostdev: add support for "managed='detach'"

Andrea Bolognani abologna at redhat.com
Tue Mar 22 11:54:12 UTC 2016


On Fri, 2016-03-18 at 11:03 -0600, Alex Williamson wrote:
> > Anyway, after reading your explanation I'm wondering if we
> > shouldn't always recommend a setup where devices that are going
> > to be assigned to guests are just never bound to any host driver,
> > as that sounds like it would have the most chances of working
> > reliably.
>> > IIUC, the pci-stubs.ids kernel parameter you mentioned above does
> > exactly that. Maybe blacklisting the host driver as well might be
> > a good idea? Anything else a user would need to do? Would the
> > user or management layer not be able to configure something like
> > that in a oVirt / OpenStack environment? What should we change
> > to make it possible or easier?
> 
> Both pci-stub.ids and blacklisting have some serious problems.  A
> common thread on the vfio-users list is that someone has two identical
> devices and wants to use one for the host and one for a VM and can't
> figure out how to make that work.

Right, because pci-stub.ids works on 'vendor product' and not
on 'domain:bus:slot.function', so if you have two or more
identical devices it's all or nothing.

> The only solution I know is to
> escalate to initramfs scripts that are smarter about which device to
> pick.  Maybe this implies that we need some initramfs integration for
> driver_override so that we can force a particular driver for a
> particular device, but that fails to acknowledge that a user may want
> the device to use the default driver, up until the point that they
> don't.

Is that really something we want to encourage? See below.

> Blacklisting has similar issues, but worse.  Not all SR-IOV drivers are
> partitioned such that there's a separate driver for PF vs VF, quite a
> few use the same driver for both.  So immediately blacklisting doesn't
> work for a large class of drivers.  In general it's even more broad
> than pci-stub.ids, for instance I might not want snd-hda-intel to bind
> to the GPU audio device used for a VM, but I definitely want
> snd-hda-intel binding to my primary audio device.  I've also found that
> marking i915 for blacklist does absolutely nothing... go figure.

Of course driver blacklisting is even more coarse-grained
than pci-stub.ids, so not suitable in a lot of situations.
Got it.

> BTW, even if we do either of these, do we still need managed='yes'
> since the device will be bound to either pci-stub or nothing and needs
> to get to vfio-pci?  I don't recall if libvirt accepts those cases or
> not.  If not, then we're unnecessarily bouncing back and forth between
> drivers even if we take a pci-stub/blacklist approach unless we inject
> another layer that actually binds them to vfio-pci.

Well, if a device is bound to pci-stub and we want to use
VFIO passthrough we're always going to have to unbind it
from pci-stub and bind it to vfio-pci, aren't we?

Shouldn't that be safe anyway? As long as the device is
never bound to a host driver...

> Let's take it one step further, what if we made an initramfs script
> that would set "vfio-pci" for the driver_override for a user specified
> list of devices.  Recall that driver_override means that only the
> driver with the matching name can bind to the device.  So now we boot
> up with the user defined set of devices without drivers.  What happens
> in either the managed='yes' or 'no' scenarios?  Logically this seems
> like exactly when we want to use 'detach'.

If managed='no', libvirt will not attempt to rebind the
device to the host driver after detaching it from the
guest, so we're good.

If managed='yes', libvirt *will* attempt to rebind it
to the host driver, but due to driver_override it will
end up being bound to vfio-pci anyway: still safe.

This looks like the perfect solution for people who
want to dedicate some host devices to VFIO passthrough
exclusively... Of course it requires implementing the
smart initramfs bits.

Could this be controlled by a kernel parameter? So you
can just add something like

  vfio-pci.devices=0000:02:00.0,0000:03:00.0

to your bootloader configuration and be sure that the
devices you've listed will never be touched by the host.

Note that I have no idea how much work implementing
something like the above would be, or whether it would
even be possible :)

> > That would give us a setup we can rely on, and cover all use
> > cases you mentioned except that of someone assigning his laptop's
> > GPU to a guest and needing the console to be available before the
> > guest has started up because no other access to the machine is
> > available. But in that case, even with managed='detach', the user
> > would need to blindly restart the machine after guest shutdown,
> > wouldn't he?
> 
> I don't want to make this issue about any one particular driver because
> I certainly hope that we'll eventually fix that one driver.

Of course :)

> The
> problem is more that this is not an uncommon scenario.  In one of my
> previous replies I listed all of the driver issues that I know about.
> In some cases we can't fix them because the driver is proprietary, in
> others we just don't have the bandwidth.  Users have far more devices
> at their disposal to test than we do, so they're likely going to
> continue to run into these issues.

Summing up the issues you listed in that message, along with
my thoughts:

  * stealing audio device from host when running a game in a
    guest, giving it back afterwards

    - desktop use case
    - seems to be working fine with managed='yes'
    - if something goes wrong when reattaching to the host,
      the user can probably still go about his business;
      rebooting the host is going to be annoying but not a
      huge deal
    - limited number of in-kernel slots means you can only
      do this a number of time before it stops working;
      again, having to reboot the host once every so-many
      guest boots is probably not a deal breaker
    - managed='detach' is not helpful here, and neither is
      the proposal above

  * NIC reserved for guest use

    - both server and desktop use case
    - may or may not handle going back and forth between
      the host and the guest
    - managed='detach' would still prevent most issues,
      assuming the host driver detaches cleanly
    - best would be if the host never touched the device
    - a solution like the one outlined above seems perfect
    - for oVirt / OpenStack, the management layer could
      take care of updating the bootloader configuration
    - for pure libvirt, that responsability would fall on
      the user
    - should virt-manager etc. rather default to
      managed='detach' when assigning a NIC to a guest?

  * GPU with binary driver

    - both server and desktop use case
    - doesn't handle dynamic unbind gracefully
    - best would be if the host never touched the device
    - a solution like the one outlined above seems perfect
    - for oVirt / OpenStack, the management layer could
      take care of updating the bootloader configuration
    - for pure libvirt, that responsability would fall on
      the user
    - managed='detach' can prevent some failures, but not
      those that happen on host driver unbind

  * Primary Intel GPU

    - desktop use case (any reason to do this for servers?)
    - will probably fail on reattach
    - mananged='detach' would prevent host crashes and the
      like
    - must assume the user has some other way to connect to
      the host, because at some point they're going to be
      unable to use the GPU from the host anyway

Have I missed anything?

> Yes, managed='no' is an
> alternative, but if we go down the path of saying 'well that feature
> sounds like foo+bar and we already do both of those, so we don't need
> that feature', then we have to start asking why do we even have
> managed='yes'?  Why do we have an autostart feature, we can clearly
> start a VM and it's the app's problem when to call that, etc.  It seems
> useful to me, but I can understand the concern about feature bloat.

If we've added redundant features in the past, then that's
only the more reason to avoid adding even more now ;)

Thanks for taking the time to reply in such detail and
providing concrete examples, it's been really helpful for
me!

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team




More information about the libvir-list mailing list