On Wed, 21 Sep 2016 04:10:53 +0000 "Tian, Kevin" <kevin.tian@intel.com> wrote:
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@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@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.)...
Not sure where you're going with this, we're not creating a programming interface for the device, that exists through the vfio API. I believe the intention here is simply a user level classification for the purpose of being able to interpret the attributes provided in a logical way.
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. :-)
And how do we generically determine the class of a parent device? We cannot assume the parent device is PCI. Thanks, Alex