Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

> Will libvirt report 'description' RO attribute, its output would be > string, so that user could be able to see the configuration of that > profile? > Daniel, Waiting for your input on this. > We can have 'class' as optional attribute. So Intel don't have to > provide 'class' attribute and they don't have to specify mandatory > attributes of that class. We would provide 'class' attribute and provide > mandatory attributes.

On 9/30/2016 10:49 AM, Kirti Wankhede wrote: > ... >>>>>> Hi Daniel, >>>>>> >>>>>> Here you are proposing to add a class named "gpu", which will make all those gpu >>>>>> related attributes mandatory, which libvirt can allow user to better >>>>>> parse/present a particular mdev configuration? >>>>>> >>>>>> I am just wondering if there is another option that we just make all those >>>>>> attributes that a mdev device can have as optional but still meaningful to >>>>>> libvirt, so libvirt can still parse / recognize them as an class "mdev". >>>>> >>>>> 'mdev' isn't a class - mdev is the name of the kernel module. The class >>>>> refers to the broad capability of the device. class would be things >>>>> like "gpu", "nic", "fpga" or other such things. The point of the class >>>>> is to identify which other attributes will be considered mandatory. >>>>> >>>>> >>>> >>>> Thanks Daniel. This class definition makes sense to me. >>>> >>>> However I'm not sure whether we should define such common mandatory attributes >>>> of a 'gpu' class now. Intel will go with a 2's power sharing of type definition... actual >>>> type name to be finalized, but an example looks like below: >>>> >>>> [GVTG-SKL-x2]: available instances (2) >>>> [GVTG-SKL-x4]: available instances (4) >>>> [GVTG-SKL-x8]: available instances (8) >>>> ... >>>> >>>> User can create different types of vGPUs simultaneously. A GVTG-SKL-x2 type >>>> vGPU will get half of the physical GPU resource, while a GVTG-SKL-x4 type will >>>> get a quarter. However it's unclear to me how we want to enumerate those >>>> resources into resolution or heads. I feel it'd be more reasonable for us to push >>>> initial libvirt mdev support w/o vgpu specific class definition, until we see >>>> a clear value of doing so (at that time we then follow Daniel's guideline to define >>>> mandatory attributes common to all GPU vendors). >>> >>> Libvirt won't report arbitrary vendor define attributes. So if we are not >>> going to define a gpu class & associated attributes, then there will be >>> no reporting of the 'heads', 'resolution', 'fb_length' data described >>> above. >>> >> >> yes, that's my point. I think nvidia may put them into the 'description' attribute >> just for descriptive purpose for now. > > > Will libvirt report 'description' RO attribute, its output would be > string, so that user could be able to see the configuration of that > profile? > Daniel, Waiting for your input on this. > We can have 'class' as optional attribute. So Intel don't have to > provide 'class' attribute and they don't have to specify mandatory > attributes of that class. We would provide 'class' attribute and provide > mandatory attributes. Thanks, Kirti