Re: [Qemu-devel] [PATCH 0/4] target-sparc: Update to use VMStateDescription

[Peter Maydell]

On 13 August 2015 at 23:37, Mark Cave-Ayland
<address@hidden> wrote:
> On 10/08/15 13:34, Peter Maydell wrote:
>
>> This patchset updates target-sparc to use VMStateDescription
>> rather than hand-written save/load functions. (This and CRIS
>> are the last two targets still using the old approach.)
>>
>> It's based on some patches from back in 2012 by Juan which
>> I've updated, rebased and made some tweaks to.
>>
>> This is a migration compatibility break; we don't care about
>> cross-version migration on SPARC guests, and not having to
>> maintain the old wire format allows a cleaner vmstate
>> description in several ways.

> Thanks for looking into this! In general the patches look very
> reasonable (although I will need to give them a more thorough testing
> when I get a chance) - my only concern is the break in migration
> compatibility. Am I right in thinking that with this patch applied a
> loadvm cannot restore a savevm from an earlier version?

Yep, that's what cross-version breaks imply.

> Not so much for qemu-system-sparc64 which is still somewhat
> experimental, however qemu-system-sparc has become very usable since
> 2012 with the advent of the cg3 and OpenBIOS changes that can now run
> Solaris/SunOS and I do have a slight concern that people could lose
> their qcow2 snapshots. Then again if we document this loudly in the
> release notes then I guess it is possible to convert a snapshot back to
> a raw, boot that and then savevm it back to the newer qcow2 again...

If there's a migration break, then the old vm-snapshot is
useless. You can load it on the old QEMU, obviously, but the
new one will never run it. The best you can do is load the VM
on the old QEMU and do a clean shutdown of it. Then you can do
a cold boot on the new QEMU.

(Note that QEMU has several meanings of 'snapshot'; the one
I have in mind here is the complete-saved-state-of-disk-and-VM
you get via savevm. Snapshots which are just saved-state-of-disk
are fine.)

Anyway, my assumption was that nobody cared much about migration
compatibility for sparc (nobody has *ever* to my knowledge complained
about compat breaks for ARM targets, which we've done fairly regularly
over the last few years). They're very hard to keep working
reliably, because you pretty much have to start defining per-version
machines (like all the pc-i440fx-2.4, pc-i440fx-2.3, etc) so that
each new version of QEMU can still produce a machine that is
exactly like the one the previous ones did, and you need to test
to make sure you haven't accidentally broken migration between
versions. So mostly we've only cared for targets where there's
serious usage as a VM target (x86, ppc, s390 more recently).
(If you've never tested 'savevm on qemu 2.3 and loadvm on 2.4"
then I'd probably put even odds on it being at least subtly broken.)

But this is in the end a target maintainer choice, so if you
really want to maintain cross-version compat I can do that.
The downside is that you end up with either (a) a really ugly
vmstate because it has to maintain unnatural field orders or
on-the-wire state or (b) a bunch of code that's only exercised
on migration from older QEMU. I think the most awkward part here
is that the old wire format wants to send the ITLB and DTLB
structures interleaved, which means you can't just define them
as being arrays of structs. Juan's original 2012 patchset actually
did the conversion as a compatible change followed by a breaking
change -- this is the patch which does the breaking-change:
http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg03818.html
The diffstat is "9 insertions(+), 163 deletions(-)"...

Let me know what you'd prefer here.

thanks
-- PMM