qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine


From: Amit Shah
Subject: Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?
Date: Tue, 22 Jul 2014 17:24:07 +0530

On (Tue) 22 Jul 2014 [12:38:14], Alex Bligh wrote:
> 
> 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?

Yes, that's what I said above.

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

Sigh; please read both my replies.

The only difference between qemu-kvm-1.0 and qemu-1.0 is the presence
of the pci-assign section in qemu-kvm-1.0.  All other output from
qemu-1.0 -> qemu-2.1 is equally applicable to qemu-kvm-1.0 ->
qemu-2.1.

> b) because I wasn't actually using your Json, but testing what made the
>    thing load in real life!

I know that; but you brought up the comparison of your experiments
with the output of the checker.  I just pointed out the checker
flagged both those things you saw (and a few others too).


                Amit



reply via email to

[Prev in Thread] Current Thread [Next in Thread]