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. 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. Thanks Yan
Why is the mechanism a 'write and test' why isn't it a 'write and ask'? i.e. the destination tells the driver what type it's received from the source, and the driver replies with a set of compatible configurations (in some preferred order).
A 'write and ask' interface would imply some sort of session in order to not be racy with concurrent users. More likely this would imply an ioctl interface, which I don't think we have in sysfs. Where do we host this ioctl?
Or one fd? f=open() write(f, "The ID I want") do { read(f, ...) -> The IDs we're offering that are compatible } while (!eof)
It's also not clear to me why the name has to be that opaque; I agree it's only got to be understood by the driver but that doesn't seem to be a reason for the driver to make it purposely obfuscated. I wouldn't expect a user to be able to parse it necessarily; but would expect something that would be useful for an error message.
If the name is not opaque, then we're going to rat hole on the format and the fields and evolving that format for every feature a vendor decides they want the user to be able to parse out of the version string. Then we require a full specification of the string in order that it be parsed according to a standard such that we don't break users inferring features in subtly different ways.
This is a lot like the problems with mdev description attributes, libvirt complains they can't use description because there's no standard formatting, but even with two vendors describing the same class of device we don't have an agreed set of things to expose in the description attribute. Thanks,
I'm not suggesting anything in anyway machine parsable; just something human readable that you can present in a menu/choice/configuration/error message. The text would be down to the vendor, and I'd suggest it start with the vendor name just as a disambiguator and to make it obvious when we get it grossly wrong.
Dave
Alex -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
_______________________________________________ intel-gvt-dev mailing list intel-gvt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev