Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices

[Alex Williamson]

On Thu, 13 Oct 2016 18:00:07 +0200
Paolo Bonzini <address@hidden> wrote:

> On 13/10/2016 16:36, Alex Williamson wrote:
> >> > 
> >> > Libvirt would have parent and type_id in XML. No two vendors can own
> >> > same parent device. So I don't think vendors would collide even having
> >> > same type_id, since <parent, type_id> pair would always be unique.  
> > 
> > We have a goal of supporting migration with mdev devices, Intel has
> > already shown this is possible.  Tying the XML representation of an
> > mdev device to a parent device is directly contradictory to that goal.
> > libvirt needs a token which is unique across vendor to be able to
> > instantiate an mdev device.  <parent, type_id> is unacceptable.  
> 
> Would the vGPU's PCI vendor and device ID be acceptable and unique?

No, the PCI vendor:device ID doesn't fully describe the device, just
look at a given GeForce configuration on the market today, a single
NVIDIA PCI device ID can have different clocks, different memory sizes,
different cooling profiles, different output ports, etc. configurable
by the card vendor.  An mdev vGPU can be the same.  The type_id needs
to encompass the entire virtual hardware configuration of the device.

Personally I think we should create a type-id the pre-pends the vendor
driver name, giving each vendor a unique namespace, and then let the
vendor driver manage the rest.  For example, an "nvidia-xyz" type_id
should define a unique mdev configuration that may be implemented
across multiple physical hardware SKUs.  libvirt xml (with
managed='yes') would list an "nvidia-xyz" device as required for the VM
and search the host for mdev parent device capable of creating such a
device.  Based on utilization, locality, or whatever parameters it
determines, libvirt would create (or re-use, if a pool) an instance of
that type_id.  Specifying a specific parent might be something we want
to allow to give the user full placement control, but I don't think it
should be required based on the sysfs API we provide to the user.
Thanks,

Alex