On 13 August 2015 at 23:37, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> 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
