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

On 06/14/2017 06:06 PM, Erik Skultety wrote: Has any thought been put towards creating an mdev pool modeled after the Storage Pool? Similar to how vHBA's are created from a Storage Pool XML definition. That way XML could be defined to keep track of a lot of different things that you may need and would require only starting the pool in order to access. Placed "appropriately" - the mdev's could already be available by the time node device state initialization occurs too since the pool would conceivably been created/defined using data from the physical device and the calls to create the virtual devices would have occurred. Much easier to add logic to a new driver/pool mgmt to handle whatever considerations there are than adding logic into the existing node device driver. Of course if there's only ever going to be a 1-to-1 relationship between whatever the mdev parent is and an mdev child, then it's probably overkill to go with a pool model; however, I was under the impression that an mdev parent could have many mdev children with various different configuration options depending on multiple factors. Thus: <gpu_pool type='mdev'> <name>Happy</name> <uuid>UUID</uuid> <source> <parent uuid='0cce8709-0640-46ef-bd14-962c7f73cc6f'/> ... </source> ... </gpu_pool> where the parent is then "found" in node device via "mdev_%s", <parent uuid..." value. One could then create (ahem) <vgpu> XML that would define specific "formats" that could be used and made active/inactive. A bit different than <volume> XML which is output only based on what's found in the storage pool source. My recollection of the whole frame work is not up to par with the latest information, but I recall there being multiple different ways to have "something" defined that could then be used by the guest based on one parent mdev. What those things are were a combination of what the mdev could support and there could be 1 or many depending on the resultant vGPU. Maybe we need a virtual white board to help describe the things ;-) If you wait long enough or perhaps if review pace would pick up, maybe creating a new driver and vir*obj infrastructure will be easier with a common virObject instance. Oh and this has a "uuid" and "name" for searches, so fits nicely. Using "pool" methodology borrows on existing storage technology except applying it to "gpu_pool" - a pool of vGPU's would be like a storage pool of volumes. Picking out a volume from a list would seem to be a mostly simple exercise. Especially if the XML/data for the vGPU can be queried to return something specific. My domain needs a XXX type vGPU - please find or create for me. I guess it's not clear which UUID is that for/from? Is this the one you were considering in the <capability>? Or in my terminology the child of the parent from about with UUID=0cce8709-0640-46ef-bd14-962c7f73cc6f. Migration makes things a bit more tricky, but from bz 1404964 which describes some thoughts Paolo had about vHBA migration - how about a way to somehow define multiple UUID's - primary/secondary... or just a "list" of <parent uuid='xxx'/>'s from which "the first" found on any given host is used. By first found I assume there's a "physical" card with a UUID on the host which has a node device with name "mdev_%s" (UUID w/_ instead of -). Using a gpu_pool type XML you could ship that around rather than trying to somehow ship across nodedev XML to define something on the migration target. John Maybe I'm lost in the weeds somewhere too ;-)