> From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Wednesday, September 21, 2016 12:43 PM > > On Wed, 21 Sep 2016 04:10:53 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] > > > 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@xxxxxxxxxx> wrote: > > > > > > > >> On 9/20/2016 3:06 AM, Alex Williamson wrote: > > > >>> On Tue, 20 Sep 2016 02:05:52 +0530 > > > >>> Kirti Wankhede <kwankhede@xxxxxxxxxx> 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. I'm not against that purpose. My main intention is that 'display' is not an accurate classification here. If we allow classification in 'display' level, it implies more finer-grained classifications may be further defined upon which vendor specific GPU resources is allowed to be configured, which might be an overkill. Here we just need a general classification like 'gpu' to cover all possible vendor-agnostic attributes beyond display. > > > 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, > Yes, this is also a good point. Thanks Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list