[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 |