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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2016-03-15 at 13:31 -0600, Alex Williamson wrote:
> So we have all sorts of driver issues that are sure to come and go over
> time and all sorts of use cases that seem difficult to predict.  If we
> know we're in a ovirt/openstack environment, managed='detach' might
> actually be a more typical use case than managed='yes'.  It still
> leaves a gap that we hope the host driver doesn't do anything bad when
> it initializes the device and hope that it releases the device cleanly,
> but it's probably better than tempting fate by unnecessarily bouncing
> it back and forth between drivers.

Is sharing a hostdev between multiple guests more solid in general?
Eg. if I have g1 and g2, both configured to use the host's GPU, can
I start up g1, shut it down, start up g2 and expect things to just
work? Hopefully that's the case because the device would go through
a more complete set up / tear down cycle.

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?

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?

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]