[libvirt] RFC: Creating mediated devices with libvirt

[Alex Williamson]

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,

Alex