All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm <kvm@vger.kernel.org>,
	qemu-devel@nongnu.org, Isaku Yamahata <yamahata@valinux.co.jp>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Juan Quintela <quintela@redhat.com>, Avi Kivity <avi@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: acpi_piix4 migration issue
Date: Mon, 29 Oct 2012 09:49:52 +0100	[thread overview]
Message-ID: <508E4330.8080004@redhat.com> (raw)
In-Reply-To: <20121028194042.GA21683@amt.cnet>

Il 28/10/2012 20:40, Marcelo Tosatti ha scritto:
> 
> qemu-kvm 1.2 -> qemu-1.3 migration fails with
> 
> Unknown savevm section type 48
> load of migration failed
> 
> Due to a fix in acpi_piix4 in qemu-kvm (attached at the end of the
> message). 
> 
> The problem is that qemu-kvm correctly uses 2 bytes for sts and 
> 2 bytes for en fields (which is their allocated size), while qemu 
> uses 4*2 bytes for each.
> 
> The fix present in qemu-kvm is correct, but, having it in qemu 1.3 would break
> qemu 1.2 -> qemu 1.3 migration (while allowing qemu-kvm 1.2 -> qemu 1.3
> migration).
> 
> Any opinions on what to do?

Bump the .version_id and .minimum_version_id to 2 and load the QEMU 1.2
state via .load_state_old.

qemu-kvm 1.2 -> qemu 1.3 migration would be broken.  qemu-kvm
downstreams that care can leave .minimum_version_id to 1.

Paolo

>     >>
>     >> +#define VMSTATE_GPE_ARRAY(_field, _state)                            \
>     >> + {                                                                   \
>     >> +     .name       = (stringify(_field)),                              \
>     >> +     .version_id = 0,                                                \
>     >> +     .num        = GPE_LEN,                                          \
>     >> +     .info       =&vmstate_info_uint16,                             \
>     >> +     .size       = sizeof(uint16_t),                                 \
>     >> +     .flags      = VMS_ARRAY | VMS_POINTER,                          \
>     >> +     .offset     = vmstate_offset_pointer(_state, _field, uint8_t),  \
>     >> + }
>     >> +
>     >>   static const VMStateDescription vmstate_gpe = {
>     >>       .name = "gpe",
>     >>       .version_id = 1,
>     >>       .minimum_version_id = 1,
>     >>       .minimum_version_id_old = 1,
>     >>       .fields      = (VMStateField []) {
>     >> -        VMSTATE_UINT16(sts, struct gpe_regs),
>     >> -        VMSTATE_UINT16(en, struct gpe_regs),
>     >> +        VMSTATE_GPE_ARRAY(sts, ACPIGPE),
>     >> +        VMSTATE_GPE_ARRAY(en, ACPIGPE),
>     >>           VMSTATE_END_OF_LIST()
>     >>       }
>     >>   };
>     >
>     > I'm no vmstate expert, but this does look odd.  Why both VMS_ARRAY and
>     > VMS_POINTER? aren't we trying to save/restore a simple 16-bit value?  Or
>     > at least we did before this patch.
>     
>     That's right. the difference is, the new member type became uint8_t*.
>     Does the following help?
>     
>     Signed-off-by: Avi Kivity <avi@redhat.com>
> 
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> index d65a7e9..9dc6f43 100644
> --- a/hw/acpi_piix4.c
> +++ b/hw/acpi_piix4.c
> @@ -221,10 +221,9 @@ static int vmstate_acpi_post_load(void *opaque, int version_id)
>   {                                                                   \
>       .name       = (stringify(_field)),                              \
>       .version_id = 0,                                                \
> -     .num        = GPE_LEN,                                          \
>       .info       = &vmstate_info_uint16,                             \
>       .size       = sizeof(uint16_t),                                 \
> -     .flags      = VMS_ARRAY | VMS_POINTER,                          \
> +     .flags      = VMS_SINGLE | VMS_POINTER,                         \
>       .offset     = vmstate_offset_pointer(_state, _field, uint8_t),  \
>   }
>  
> 
> 
> 
> 


      reply	other threads:[~2012-10-29  8:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-28 19:40 acpi_piix4 migration issue Marcelo Tosatti
2012-10-29  8:49 ` Paolo Bonzini [this message]

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=508E4330.8080004@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=yamahata@valinux.co.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.