>>>>>>>
>>>>>>> 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