On Thu, 13 Oct 2016 18:00:07 +0200 Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
