[libvirt] RFC: Creating mediated devices with libvirt

[Pavel Hrdina]

On Thu, Jun 22, 2017 at 09:28:57AM -0600, Alex Williamson wrote:
> On Thu, 22 Jun 2017 17:14:48 +0200
> Erik Skultety <eskultet at redhat.com> wrote:
> 
> > [...]
> > > >
> > > > ^this is the thing we constantly keep discussing as everyone has a slightly
> > > > different angle of view - libvirt does not implement any kind of policy,
> > > > therefore the only "configuration" would be the PCI parent placement - you say
> > > > what to do and we do it, no logic in it, that's it. Now, I don't understand
> > > > taking care of the guesswork for the user in the simplest manner possible as
> > > > policy rather as a mere convenience, be it just for developers and testers, but
> > > > even that might apparently be perceived as a policy and therefore unacceptable.
> > > >
> > > > I still stand by idea of having auto-creation as unfortunately, I sort of still
> > > > fail to understand what the negative implications of having it are - is that it
> > > > would get just unnecessarily too complex to maintain in the future that we would
> > > > regret it or that we'd get a huge amount of follow-up requests for extending the
> > > > feature or is it just that simply the interpretation of auto-create == policy?  
> > >
> > > The increasing complexity of the qemu driver is a significant concern with
> > > adding policy based logic to the code. THinking about this though, if we
> > > provide the inactive node device feature, then we can avoid essentially
> > > all new code and complexity QEMU driver, and still support auto-create.
> > >
> > > ie, in the domain XML we just continue to have the exact same XML that
> > > we already have today for mdevs, but with a single new attribute
> > > autocreate=yes|no
> > >
> > >   <devices>
> > >     <hostdev mode='subsystem' type='mdev' model='vfio-pci' autocreate="yes">
> > >     <source>
> > >       <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'>  
> > 
> > So, just for clarification of the concept, the device with ^this UUID will have
> > had to be defined by the nodedev API by the time we start to edit the domain
> > XML in this manner in which case the only thing the autocreate=yes would do is
> > to actually create the mdev according to the nodedev config, right? Continuing
> > with that thought, if UUID doesn't refer to any of the inactive configs it will
> > be an error I suppose? What about the fact that only one vgpu type can live on
> > the GPU? even if you can successfully identify a device using the UUID in this
> > way, you'll still face the problem, that other types might be currently
> > occupying the GPU and need to be torn down first, will this be automated as
> > well in what you suggest? I assume not.
> > 
> > >     </source>
> > >     </hostdev>
> > >   </devices>
> > >
> > > In the QEMU driver, then the only change required is
> > >
> > >    if (def->autocreate)
> > >        virNodeDeviceCreate(dev)  
> > 
> > Aha, so if a device gets torn down on shutdown, we won't face the problem with
> > some other devices being active, all of them will have to be in the inactive
> > state because they got torn down during the last shutdown - that would work.
> 
> 
> I'm not familiar with how inactive devices would be defined in the
> nodedev API, would someone mind explaining or providing an example
> please?  I don't understand where the metadata is stored that describes
> the what and where of a given UUID.  Thanks,

It would basically copy what we do for domains.  Currently there is
virNodeDeviceCreateXML() which takes the XML definitions and creates a
new active node device and virNodeDeviceDestroy() which takes as
argument an object of existing active node device.

We would extend the functionality with new APIs:

  - virNodeDeviceCreate() which would take as argument an object of
    existing inactive node device.

  - virNodeDeviceDefineXML() would define the node device as inactive.

With the virNodeDeviceDefineXML() you would create a list of predefined
inactive devices which could be obtained by
virConnectListAllNodeDevices() for example.

Internally we would store XML files the same way as we do for domains,
somewhere in "/etc/libvirt/..." and like with domains the APIs would
work with these files.

In virsh terms there would be similar analogy to the domain commands:

"virsh nodedev-start" could simply map to virNodeDeviceCreate() and
would work like "virsh start" for domains and "virsh nodedev-define"
woudl map to virNodeDeviceDefineXML() and work the same way as
"virsh define".  You could simply list the predefined mdev devices
using "virsh nodedev-list", get UUID of existing mdev device and use it
in a domain.

In virt-manager there could be new type of hostdev device where you
could select on of existing mdev devices from a drop-down list where
virt-manager would show nice user-friendly descriptions of the mdev
devices but under the hood it would put the UUID in the domain XML.

Pavel

> 
> Alex
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170622/1ab5211c/attachment-0001.sig>