|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] qemu-traditional: Bump piix4acpi save-record version_id
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. 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. You intend to fix this in XenServer
by allocating a new savefile version 3 for your users.
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.
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.
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 ?
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |