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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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

If you want to make this migration work then excellent and I'd be
happy to bump savefile version numbers for that.  But surely we'd want
to know that we weren't going to have to do it again (whether in this
driver or another part of qemu), which would involve doing some kind
of research or testing which AIUI you aren't anywhere near completing
yet.  Otherwise we'll find ourselves incurring the savefile version
bump compatibility cost on multiple occasions, for no benefit.

> I will be doing my upmost to ensure that this doesn't occur when we move to
> qemu-upstream.

That would be good :-).  Three of these incompatible savefile formats
is certainy enough ...

Thanks,
Ian.

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