On 22 Jul 2014, at 11:54, Amit Shah <amit.s...@redhat.com> wrote: >> >> This one, together with the PIIX4 one (which for some reason doesn't >> show up) where the two I hit, after manually fixing the rom sizes >> stuff on the command line. >> >> Apparently "flags" and "channels" are pseudonyms. > > No, they're not; flags is an extra 4-byte param in qemu-kvm-1.0, which > doesn't exist in qemu-1.0. > > In qemu-2.1 -M 1.0, "flags" got renamed to "channels[0].irq_disabled", > which is also flagged.
I was basing that on the comment in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 --- a/hw/timer/i8254_common.c +++ b/hw/timer/i8254_common.c @@ -267,7 +267,12 @@ static const VMStateDescription vmstate_pit_common = { .pre_save = pit_dispatch_pre_save, .post_load = pit_dispatch_post_load, .fields = (VMStateField[]) { - VMSTATE_UINT32_V(channels[0].irq_disabled, PITCommonState, 3), + /* qemu-kvm version_id=2 had 'flags' here which is equivalent + * This fixes incoming migration from qemu-kvm 1.0, but breaks + * incoming migration from qemu < 1.1 + */ + //VMSTATE_UINT32_V(channels[0].irq_disabled, PITCommonState, 3), + VMSTATE_UINT32(channels[0].irq_disabled, PITCommonState), VMSTATE_STRUCT_ARRAY(channels, PITCommonState, 3, 2, vmstate_pit_channel, PITChannelState), VMSTATE_INT64(channels[0].next_transition_time, I think what this means is that flags is equivalent to channels[0].irq_disabled, yes? >> The piix4_m thing >> is that qemu-kvm-1.0 is actually using version 3 but says it's >> using version 2, which is perhaps why it doesn't show up in your >> test. > > You're looking at the wrong output. You should see one message back, > where I compare qemu-1.0 with qemu-2.1 -M pc-1.0. That has the > piix4_pm version mismatch flagged. Don't think I am a) because I'm using qemu-kvm-1.0, not qemu-1.0. You looked at qemu-1.0 in the previous message; that's not directly relevant for what I'm looking at as my source is qemu-kvm-1.0 (qemu vs qemu-kvm). b) because I wasn't actually using your Json, but testing what made the thing load in real life! -- Alex Bligh
