Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

[Alex Bligh]

On 22 Jul 2014, at 11:54, Amit Shah <address@hidden> 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