[libvirt] [RFC PATCH 00/16] Introduce vGPU mdev framework to libvirt

[Daniel P. Berrange]

On Tue, Feb 07, 2017 at 05:48:23PM +0100, Erik Skultety wrote:
> On Mon, Feb 06, 2017 at 04:44:37PM +0000, Daniel P. Berrange wrote:
> > On Mon, Feb 06, 2017 at 01:19:42PM +0100, Erik Skultety wrote:
> > > Finally. It's here. This is the initial suggestion on how libvirt might
> > > interract with the mdev framework, currently only focussing on the non-managed
> > > devices, i.e. those pre-created by the user, since that will be revisited once
> > > we all settled on how the XML should look like, given we might not want to use
> > > the sysfs path directly as an attribute in the domain XML. My proposal on the
> > > XML is the following:
> > > 
> > > <hostdev mode='subsystem' type='mdev'>  
> > >     <source>
> > >         <!-- this is the host's physical device address -->
> > >         <address domain='0x0000' bus='0x00' slot='0x00' function='0x00'>
> > >         <uuid>vGPU_UUID<uuid>
> > >     <source>
> > >     <!-- target PCI address can be omitted to assign it automatically -->
> > > </hostdev>
> > > 
> > > So the mediated device is identified by the physical parent device visible on
> > > the host and a UUID which allows us to construct the sysfs path by ourselves,
> > > which we then put on the QEMU's command line.
> > > 
> > > A few remarks if you actually happen to have a machine to test this on:
> > > - right now the mediated devices are one-time use only, i.e. they have to be
> > > recreated before every machine boot
> > > - I wouldn't recommend assigning multiple vGPUs to a single domain
> > > 
> > > Once this series is sorted out, we can then continue with 'managed=yes' where
> > > as Laine pointed out [1], we need to figure out how exactly should the
> > > management layer hint libvirt which vGPU type should be used for device
> > > instantiation.
> > 
> > You seem to be suggesting that managed=yes with mdev devices would
> > cause create / delete of a mdev device from a specified parent.
> > 
> > This is rather different semantics from what managed=yes does with
> > PCI device assignment today.  There the managed=yes flag is just
> > about controlling host device driver attachment. ie whether libvirt
> > will manually bind to vfio.ko, or expect the admin to have bound
> > it to vfio.ko before hand. I think it is important to keep that
> > concept as is for mdev too.
> 
> If the managed attribute was used with other devices beside PCI, then sure, we
> should keep the concept, however, since only PCI devices support it and now we
> have another device type that potentially might have a use for such an
> attribute I think it's perfectly reasonable to alter the logic behind that
> attribute in favor of the new possibilities to device management which mdev
> framework is providing us with which in this case is dynamic creation and
> removal of a mediated device.

No we really shouldn't use one attribute to overload completely
different semantics. As I say, we may well find we want to implement
the existing PCI semantics for mdev devices too.

If we want to auto-create, that should be a different attribute
eg 'autocreate=yes|no'

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|