On Tue, 9 Jun 2020 20:37:31 -0400 Yan Zhao <yan.y.z...@intel.com> wrote:
> On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote: > > > > > I tried to simplify the problem a bit, but we keep going backwards. > > > > > If > > > > > the requirement is that potentially any source device can migrate to > > > > > any > > > > > target device and we cannot provide any means other than writing an > > > > > opaque source string into a version attribute on the target and > > > > > evaluating the result to determine compatibility, then we're requiring > > > > > userspace to do an exhaustive search to find a potential match. That > > > > > sucks. > > > > > hi Alex and Dave, > do you think it's good for us to put aside physical devices and mdev > aggregation > for the moment, and use Alex's original idea that > > + Userspace should regard two mdev devices compatible when ALL of below > + conditions are met: > + (0) The mdev devices are of the same type > + (1) success when reading from migration_version attribute of one mdev > device. > + (2) success when writing migration_version string of one mdev device to > + migration_version attribute of the other mdev device. I think Pandora's box is already opened, if we can't articulate how this solution would evolve to support features that we know are coming, why should we proceed with this approach? We've already seen interest in breaking rule (0) in this thread, so we can't focus the solution on mdev devices. Maybe the best we can do is to compare one instance of a device to another instance of a device, without any capability to predict compatibility prior to creating devices, in the case on mdev. The string would need to include not only the device and vendor driver compatibility, but also anything that has modified the state of the device, such as creation time or post-creation time configuration. The user is left on their own for creating a compatible device, or filtering devices to determine which might be, or which might generate, compatible devices. It's not much of a solution, I wonder if anyone would even use it. > and what about adding another sysfs attribute for vendors to put > recommended migration compatible device type. e.g. > #cat > /sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/i915-GVTg_V5_8/migration_compatible_devices > parent id: 8086 591d > mdev_type: i915-GVTg_V5_8 > > vendors are free to define the format and conent of this > migration_compatible_devices > and it's even not to be a full list. > > before libvirt or user to do live migration, they have to read and test > migration_version attributes of src/target devices to check migration > compatibility. AFAICT, free-form, vendor defined attributes are useless to libvirt. Vendors could already put this information in the description attribute and have it ignored by userspace tools due to the lack of defined format. It's also not clear what value this provides when it's necessarily incomplete, a driver written today cannot know what future drivers might be compatible with its migration data. Thanks, Alex
