Re: [libvirt] RFC: Creating mediated devices with libvirt

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(a)redhat.com&gt; 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list