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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/12/2013 16:23, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] qemu-traditional: Bump piix4acpi 
> save-record version_id"):
>> On 16/12/2013 14:47, Ian Jackson wrote:
>>
>>       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.
> Yes, that's what I meant; sorry for not being clear.
>
>>     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.
> I'm not sure I understand.  You're worried that if you apply this
> version bump only to the XenServer version of piix4acpi, and we
> (Xen.org) in the future change qemu-xen-traditional to assign version
> 3, the change that we make would "break" your change somehow when you
> merged your change with ours ?
>
> But surely when that occurred you'd get a textual merge conflict on
> this piece of code, so you would notice.  Obviously you'd have to
> decide what to do about it but the obvious answer would be to allocate
> yourself save format 4 in the private numbering space which was (de
> facto) created by the original XenServer bug.
>
> And in practice I don't foresee us wanting to bump our own format any
> time soon.  qemu-xen-traditional is in the deep freeze
> maintenance-wise.

By "break", I mean "require some more cunning solution to the problem to
be found".  It will certainly not be subtle in terms of merge conflicts.

If upstream were to introduce a new v3 record with a different format,
XenServer's fix would have to automatically bump up to v4, and extend
the detection logic.  The amount of hacking would have to increase every
time upstream changed.

>
>> 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.
> If it is not intended to support migration of savefiles between
> XenServer and Xen.org's qemu-xen-traditional, then I don't see why it
> matters that XenServer has a private incompatible savefile format.

It matters, because of the maintenance effort of taking incremental
improvements from upstream.

I refer you to
https://github.com/xenserver/xen-4.3.pg/blob/master/xen-legacy-win-xenmapspace-quirks.patch
which shows the amount of hackary required when it is not possible to
take a preemtive step like this to prevent it breaking in the future.


I guess this all comes down to how likely the piix4acpi object version
id is to change in the future.  It is certainly possible for me to fix
this in XenServer only, and might be the better way if it is fairly
certain that none of this is going to change in qemu-traditional going
forward.

~Andrew

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