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

[Kirti Wankhede]

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