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> 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> 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. :-)
Thanks
Kevin