3:51 a.m.
On Fri, Jul 17, 2020 at 10:12:58AM -0600, Alex Williamson wrote:
<...>
> yes, in another reply, Alex proposed to use an interface in json
format.
> I guess we can define something like
>
> { "self" :
> [
> { "pciid" : "8086591d",
> "driver" : "i915",
> "gvt-version" : "v1",
> "mdev_type" : "i915-GVTg_V5_2",
> "aggregator" : "1",
> "pv-mode" : "none",
> }
> ],
> "compatible" :
> [
> { "pciid" : "8086591d",
> "driver" : "i915",
> "gvt-version" : "v1",
> "mdev_type" : "i915-GVTg_V5_2",
> "aggregator" : "1"
> "pv-mode" : "none",
> },
> { "pciid" : "8086591d",
> "driver" : "i915",
> "gvt-version" : "v1",
> "mdev_type" : "i915-GVTg_V5_4",
> "aggregator" : "2"
> "pv-mode" : "none",
> },
> { "pciid" : "8086591d",
> "driver" : "i915",
> "gvt-version" : "v2",
> "mdev_type" : "i915-GVTg_V5_4",
> "aggregator" : "2"
> "pv-mode" : "none, ppgtt, context",
> }
> ...
> ]
> }
>
> But as those fields are mostly vendor specific, the userspace can
> only do simple string comparing, I guess the list would be very long as
> it needs to enumerate all possible targets.
This ignores so much of what I tried to achieve in my example :(
sorry, I just was eager to show and confirm the way to list all compatible
combination of mdev_type and mdev attributes.
> also, in some fileds like "gvt-version", is there a simple way to express
> things like v2+?
That's not a reasonable thing to express anyway, how can you be certain
that v3 won't break compatibility with v2? Sean proposed a versioning
scheme that accounts for this, using an x.y.z version expressing the
major, minor, and bugfix versions, where there is no compatibility
across major versions, minor versions have forward compatibility (ex. 1
-> 2 is ok, 2 -> 1 is not) and bugfix version number indicates some
degree of internal improvement that is not visible to the user in terms
of features or compatibility, but provides a basis for preferring
equally compatible candidates.
right. if self version is v1, it can't know its compatible version is
v2. it can only be done in reverse. i.e.
when self version is v2, it can list its compatible version is v1 and
v2.
and maybe later when self version is v3, there's no v1 in its compatible
list.
In this way, do you think we still need the complex x.y.z versioning scheme?
> If the userspace can read this interface both in src and target and
> check whether both src and target are in corresponding compatible list, I
> think it will work for us.
>
> But still, kernel should not rely on userspace's choice, the opaque
> compatibility string is still required in kernel. No matter whether
> it would be exposed to userspace as an compatibility checking interface,
> vendor driver would keep this part of code and embed the string into the
> migration stream. so exposing it as an interface to be used by libvirt to
> do a safety check before a real live migration is only about enabling
> the kernel part of check to happen ahead.
As you indicate, the vendor driver is responsible for checking version
information embedded within the migration stream. Therefore a
migration should fail early if the devices are incompatible. Is it
but as I know,
currently in VFIO migration protocol, we have no way to
get vendor specific compatibility checking string in migration setup stage
(i.e. .save_setup stage) before the device is set to _SAVING state.
In this way, for devices who does not save device data in precopy stage,
the migration compatibility checking is as late as in stop-and-copy
stage, which is too late.
do you think we need to add the getting/checking of vendor specific
compatibility string early in save_setup stage?
really libvirt's place to second guess what it has been directed
to do?
if libvirt uses the scheme of reading compatibility string at source and
writing for checking at the target, it can not be called "a second guess".
It's not a guess, but a confirmation.
Why would we even proceed to design a user parse-able version
interface
if we still have a dependency on an opaque interface? Thanks,
one reason is that
libvirt can't trust the parsing result from
openstack.
Another reason is that libvirt can use this opaque interface easier than
another parsing by itself, in the fact that it would not introduce more
burden to kernel who would write this part of code anyway, no matter
libvirt uses it or not.
Thanks
Yan