[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration |
Date: |
Wed, 21 Sep 2016 04:10:53 +0000 |
> From: Kirti Wankhede [mailto:address@hidden
> 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 <address@hidden> wrote:
> >
> >> On 9/20/2016 3:06 AM, Alex Williamson wrote:
> >>> On Tue, 20 Sep 2016 02:05:52 +0530
> >>> Kirti Wankhede <address@hidden> 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
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, (continued)
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/28
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/28
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Neo Jia, 2016/09/28
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/28
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/29
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, Neo Jia, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration,
Tian, Kevin <=
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/22
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/23
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Message not available
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21