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