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: Thu, 29 Sep 2016 19:52:32 +0530

>>>>>>>>
>>>>>>>> 7. Hot-plug
>>>>>>>>
>>>>>>>> It is same syntax to create a virtual device for hot-plug.      
>>>>>>>
>>>>>>> How do groups work with hotplug?  Can a device be creating into an
>>>>>>> existing, running group?  Can a device be removed from an existing,
>>>>>>> running group?  Thanks,
>>>>>>>       
>>>>>>
>>>>>> Group is for vendor driver to decide when to commit resources for a
>>>>>> group of devices to support multiple devices in a domain. It will be
>>>>>> upto vendor driver how it manage it.    
>>>>>
>>>>> Then it's not sufficiently specified for libvirt to use.  Thanks,
>>>>>     
>>>>
>>>> Can you clarify what if required for libvirt to use?  
>>>
>>> Everything we're discussing above.  We can't simply say that group
>>> management is defined by the vendor driver, that means that libvirt
>>> needs to know how to uniquely behave for each vendor driver.  We want
>>> to create a consistent framework where libvirt doesn't care what the
>>> vendor driver is.  Therefore we need to make group manipulation fully
>>> specified, regardless of the vendor driver.  Thanks,
>>>  
>>
>> There is no communication between different vendor drivers. So if
>> libvirt creates a group with one device from one vendor and one device
>> from another vendor, both vendor driver would think they have a single
>> device and accordingly commit resources for that single device from its
>> own driver. Ideally nothing would fail. But that is not the main aim of
>> grouping, right?
>>
>> To make this independent of vendor driver, we had initial proposal of
>> having same UUID and different instance numbers. But that was also not
>> acceptable.
> 
> We're defining the infrastructure, we get to define the rules, but we
> need to define all the rules so that libvirt can actually implement to
> them.  We can't say "groups are this nebulous thing and each vendor
> will manage them however they want", nobody wants to care that NVIDIA
> did it one way and Intel did it another and we need to support both.
> That's a design failure.  Therefore we \must\ make the group definition
> we need well specified, any hopefully generic enough that others can
> use it.  If they cannot then we'd need to add a new type of group.
> Therefore we need to \specify\ things like for what set of mdev should
> a group be created?  Do I need a group for a single device?  How do we
> introspect a group to know which mdevs it contains?  Can we dynamically
> add or remove mdev devices from a group?  Can we attach multiple
> groups to the same user?  Can we change the association of an mdev
> device without removing it and recreating it? etc, etc, etc.  We don't
> need vendor coordination, we need a specification of exactly how this
> type of group is meant to work. Thanks,
> 

We decided to handle "multiple vGPUs per VM" through internal design
changes. With that we don't need grouping in mdev framework. Hope this
helps to accelerate and settle on sysfs interface soon.

Thanks,
Kirti






reply via email to

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