[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] qemu-traditional: Bump piix4acpi save-record version_id
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
|