qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration


From: Kirti Wankhede
Subject: Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
Date: Sat, 24 Sep 2016 00:04:00 +0530


On 9/23/2016 12:55 AM, Tian, Kevin wrote:
>> From: Kirti Wankhede [mailto:address@hidden
>> Sent: Wednesday, September 21, 2016 12:23 AM
>>>
>>>>>  I have
>>>>> a hard time believing that a given vendor can even allocate unique type
>>>>> ids for their own devices.  Unique type id across vendors is not
>>>>> practical.  So which attribute are we actually using to identify which
>>>>> type of mdev device we need and why would we ever specify additional
>>>>> attributes like fb_length?  Doesn't the vendor guarantee that "GRID
>>>>> M60-0B" has a fixed setup of those attributes?
>>>>>
>>>>
>>>> Specifying attributes here is not our requirement. Yes we have fixed set
>>>> of attributes for "GRID-M60-0B" and on.
>>>> We are defining the attributed here for "display" class for all other
>>>> vendor of gpu can use.
>>>>
> 
> Hi, Kirti, 
> 
> We decide to go with above type-based interface for KVMGT, with fixed setup 
> of attributes too. If both Intel and NVIDIA solutions use such fixed manner,
> can we go with a proposal which doesn't include 'class' extension for now?
> Later if there is a concrete usage requiring such class-specific attribute 
> setting,
> then it's easy to extend following discussion in this thread. I'm thinking 
> how we
> can converge the discussion here into something simple enough (and extensible)
> to accelerate upstreaming of both Intel/NVIDIA solutions...
> 

Hi Kevin,

We have fixed set of attributes which are GPU/graphics specific, like
framebuffer_length, resolution, number of heads, max supported instances.
If you are going with fixed set of attributes, how are the vGPU types on
KVMGT looks like from attributes point of view? attributes are graphics
specific attributes?

Thanks,
Kirti



reply via email to

[Prev in Thread] Current Thread [Next in Thread]