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.