[libvirt] [RFC PATCH 00/16] Introduce vGPU mdev framework to libvirt
Daniel P. Berrange
berrange at redhat.com
Tue Feb 7 17:07:48 UTC 2017
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/ :|
More information about the libvir-list
mailing list