Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration

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

> > 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(a)redhat.com / Manchester, UK _______________________________________________ intel-gvt-dev mailing list intel-gvt-dev(a)lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev