Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

> From: Kirti Wankhede [mailto:kwankhede@nvidia.com] > Sent: Wednesday, September 21, 2016 12:23 AM > > > On 9/20/2016 8:13 PM, Alex Williamson wrote: > > On Tue, 20 Sep 2016 19:51:58 +0530 > > Kirti Wankhede <kwankhede(a)nvidia.com&gt; wrote: > > > >> On 9/20/2016 3:06 AM, Alex Williamson wrote: > >>> On Tue, 20 Sep 2016 02:05:52 +0530 > >>> Kirti Wankhede <kwankhede(a)nvidia.com&gt; wrote: > >>> > >>>> Hi libvirt experts, > >>>> > >>>> > >>>> 'create': > >>>> Write-only file. Mandatory. > >>>> Accepts string to create mediated device. > >>>> > >>>> 'name': > >>>> Read-Only file. Mandatory. > >>>> Returns string, the name of that type id. > >>>> > >>>> 'fb_length': > >>>> Read-only file. Mandatory. > >>>> Returns <number>{K,M,G}, size of framebuffer. > >>> > >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are > >>> just one user of mediated devices. > >>> > >> > >> As per our discussion in BOF, we would define class and its attributes. > >> As I mentioned above these are attributes of "display" class. > > > > Just as I didn't know here, how does libvirt know the class of a given > > type id? > > > > Yes, we need some way to identify the class as Daniel mentioned in his > suggestion. Add a file 'class' in mdev_supported_types that would return > the class. > > 'display' class or 'gpu' class? display represents only part of GPU functionalities. I assume you want to provide an unique class ID for each type, instead of allowing multiple classes each identifying a subset of controllable GPU resources (e.g. 'display', 'render', etc.)...

for unique class ID, I once considered whether it could be directly inherited from class of parent device, since typically a vendor driver creates mdev devices using the same type as physical device. But later I realized one potential value of keep a class field for mdev types, e.g. if we want to extend mdev to FPGA which could be programmed as different classes of functionalities. :-)