Re: [RFC v2] libvirt vGPU QEMU integration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]