Re: [Xen-devel] [PATCH] qemu-traditional: Bump piix4acpi save-record version_id

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/12/2013 14:47, Ian Jackson wrote:

Andrew Cooper writes ("[PATCH] qemu-traditional: Bump piix4acpi save-record version_id"):

Sadly, because of a buggy attempt to revert c/s
ce3b7ce68426ea6249bb411f26b376d459c45450 (piix4acpi, xen: change in
ACPI to match the change in the BIOS) "for debugging purposes" which
has remained present in XenServer for several releases, an
incompatibility in the Qemu save record went unnoticed until now
when I tried to clean up the patch queue.

The result is that save-records for XenServer 6.0 to 6.2 advertise a
piix4acpi record of version 2, but with the content of version 1
record (also corrupting everything later in the stream, but as this
is the last record and qemu doesn't care about junk in the end of
the record, this went completely unnoticed).

While this can of-course be fixed by us locally, reserving version_id 3
upstream is the only way to prevent further incompatibilities if/when the
piix4acpi object gets further development/bugfixes which require a change to
the save-record.

Just to be clear, what you are saying is this: there is no bug in
upstream.

Correct

  However, some versions of XenServer have a bug which means
that they generate broken savefiles with declared version 2 which are
not compatible with upstream's.

Correct

  You intend to fix this in XenServer
by allocating a new savefile version 3 for your users.

This is only the version of the piix4acpi object inside the stream, not of the whole stream itself.

Upstream can consider version 2 and version 3 identical.  XenServer will further have to declare version 2 to be version 1 for the purposes of interpreting the stream.

As this is a pipe, and the difference in the stream is the presence/lack of a single integer, I see no practical way to try and evaluate whether it is a buggy v2 record without trusting the version_id.

If anyone has a clever solution that could prevent the need to bump the version then I would love to hear it.  I just cant see a practical alternative at the moment.

You would like Xen.org's qemu-xen-traditional to also bump the
savefile version to 3 because that would avoid your continuing
divergence on this point from Xen.org's qemu-xen-traditional.

Correct

This is in principle allowable because we guarantee forward but not
backward migration compatibility.  However, it does have a cost:
without this change, it is possible that in practice reverse migration
or save/restore from 4.4 to 4.3 would work.  I haven't thought through
whether this is in fact possible at the moment.

I hadn't considered this point.  The version compatibility statement declares "Migrating down a version (e.g. from release N+1 down to release N) is not normally supported."  I cant remember whether there have been any change in Xen itself which would prevent this from working.

It seems to me that your proposal is only useful if as a result (at
least) XenServer's "version 3" savefiles are compatible with Xen.org's
"version 3" qemu-xen-traditional savefiles.  What steps have you taken
to verify that this is the case ?  What do you think the usage
scenario of this compatibility would be - some kind of migration to or
from XenServer ?

The main purpose of this is so someone doesn't come along with a new improvement/bugfix and bumps the piix4acpi version from 2 to 3 upstream, and break the hack I have to make XenServer compatible with its buggy past self.

As far as validating, I have confirmed that we have no patches touching piix4acpi_save, so it is the same as upstream.

I honestly don't know how well a VM would do being migrated between XenServer and another qemu-traditional based toolstack.  I suspect we have some incompatibilities elsewhere, but I am still wading through the years and years detritus which has accumulated in our patch queue.

I will be doing my upmost to ensure that this doesn't occur when we move to qemu-upstream.

~Andrew

An aside: I haven't ever tried a migration (or save/restore) from
qemu-xen-traditional to qemu-xen-upstream but I can't see it working
because the set of devices will be different.  So I think
savefile compatibility between qemu-xen-traditional and
qemu-xen-traditional is not a consideration.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel