[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
From: |
Kirti Wankhede |
Subject: |
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration |
Date: |
Fri, 7 Oct 2016 10:46:22 +0530 |
Ping..
Pulling the questions at the top.
>> 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
On 10/3/2016 1:50 PM, Kirti Wankhede wrote:
>
>
> 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
>