qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?
Date: Tue, 22 Jul 2014 17:24:07 +0530	[thread overview]
Message-ID: <20140722115407.GF18209@grmbl.mre> (raw)
In-Reply-To: <5AB9C3BF-1A4F-4942-A433-1724BBFC9D23@alex.org.uk>

On (Tue) 22 Jul 2014 [12:38:14], Alex Bligh wrote:
> 
> On 22 Jul 2014, at 11:54, Amit Shah <amit.shah@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

  reply	other threads:[~2014-07-22 11:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 23:33 [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix? Alex Bligh
2014-07-19  5:51 ` Paolo Bonzini
2014-07-19  7:10   ` Alex Bligh
2014-07-19  7:30     ` Paolo Bonzini
2014-07-19  8:43       ` Alex Bligh
2014-07-19  8:54         ` Peter Maydell
2014-07-19  8:59           ` Alex Bligh
2014-07-19 10:53         ` Paolo Bonzini
2014-07-19 11:37           ` Alex Bligh
2014-07-21 10:22             ` Paolo Bonzini
2014-07-21 13:59               ` Alex Bligh
2014-07-21 14:11                 ` Paolo Bonzini
2014-07-21 14:35                   ` Alex Bligh
2014-07-21 14:14                 ` Paolo Bonzini
2014-07-22  7:11             ` Amit Shah
2014-07-22  9:50               ` Amit Shah
2014-07-22  9:55                 ` Paolo Bonzini
2014-07-22 10:22                   ` Amit Shah
2014-07-22 10:32                     ` Alex Bligh
2014-07-22 10:54                       ` Amit Shah
2014-07-22 11:38                         ` Alex Bligh
2014-07-22 11:54                           ` Amit Shah [this message]
2014-07-22 12:12                             ` Paolo Bonzini
2014-07-22 12:19                               ` Alex Bligh
2014-07-22 12:47                                 ` Amit Shah
2014-07-22 12:40                               ` Amit Shah
2014-07-22 12:15                             ` Alex Bligh
2014-07-22 12:44                               ` Amit Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140722115407.GF18209@grmbl.mre \
    --to=amit.shah@redhat.com \
    --cc=alex@alex.org.uk \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).