All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cole Robinson <crobinso@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] define qemukvm-1.2 machine type
Date: Mon, 14 Jan 2013 22:45:00 -0500	[thread overview]
Message-ID: <50F4D0BC.9020207@redhat.com> (raw)
In-Reply-To: <20121212223919.GA3190@amt.cnet>

On 12/12/2012 05:39 PM, Marcelo Tosatti wrote:
> 
> To allow migration from qemu-kvm-1.2, where cirrus device has 16 megabytes
> of RAM.
> 
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> 

Hi Marcelo, I'm trying to sort through this again.

> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 19e342a..ead4b6b 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -347,6 +347,26 @@ static QEMUMachine pc_machine_v1_2 = {
>      },
>  };
>  
> +#define QEMUKVMPC_COMPAT_1_2 \
> +        {\
> +            .driver   = "cirrus-vga",\
> +            .property = "vgamem_mb",\
> +            .value    = "16",\
> +        }
> +
> +static QEMUMachine qemukvmpc_machine_v1_2 = {
> +    .name = "qemukvm-pc-1.2",
> +    .alias = "pc",
> +    .desc = "Standard PC",
> +    .init = pc_init_pci,
> +    .max_cpus = 255,
> +    .compat_props = (GlobalProperty[]) {
> +        QEMUKVMPC_COMPAT_1_2,
> +        PC_COMPAT_1_2,
> +        { /* end of list */ }
> +    },
> +};
> +
>  #define PC_COMPAT_1_1 \
>          PC_COMPAT_1_2,\
>          {\
> @@ -645,6 +665,7 @@ static QEMUMachine xenfv_machine = {
>  
>  static void pc_machine_init(void)
>  {
> +    qemu_register_machine(&qemukvmpc_machine_v1_2);
>      qemu_register_machine(&pc_machine_v1_4);
>      qemu_register_machine(&pc_machine_v1_3);
>      qemu_register_machine(&pc_machine_v1_2);
> 

As previously mentioned in the thread, a back compat machine type doesn't help
us out in Fedora. For the past 3 years all qemu usage in fedora has been using
qemu-kvm.git, so the only incoming migration we care about has to deal with
the qemu-kvm migration incompatibilities.

Libvirt always specifies an explicit machine type and carries it for the life
of the VM. What we want is for 'qemu-kvm-1.2 -M pc-1.2' to migrate seamlessly
into 'qemu-1.3+ -M pc-1.2' without the user or libvirt having to change
machine type.

So what we want to carry in Fedora is:


diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index aa3e7f4..b8f5f8a 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -315,6 +315,10 @@ static QEMUMachine pc_machine_v1_3 = {
             .driver   = "VGA",\
             .property = "mmio",\
             .value    = "off",\
+        },{\
+            .driver   = "cirrus-vga",\
+            .property = "vgamem_mb",\
+            .value    = stringify(8),\
         }

 static QEMUMachine pc_machine_v1_2 = {


That sticks the cirrus compat block on the end of PC_COMPAT_1_2, which should
fix cirrus migration from qemu-kvm for all machine types <= pc-1.2. Obviously
this isn't suitable for upstream but we can hide it behind something like
./configure --qemu-kvm-migrate-compat

The other migrate bit is the comment you added to hw/acpi_piix4.c:

/* qemu-kvm 1.2 uses version 3 but advertised as 2
 * To support incoming qemu-kvm 1.2 migration, change version_id
 * and minimum_version_id to 2 below (which breaks migration from
 * qemu 1.2).
 *
 */

That's a bit more problematic. Upstream has minimum_version_id=3, so if we
carry version_id=2 in Fedora, our packages will never be able to migrate to an
upstream qemu version, even a VM using pc-1.3 that was added after qemu-kvm
was deprecated.

Is it safe to just set minimum_version_id=2 in qemu.git and be done with it?
It at least doesn't blow up[1] going from qemu-kvm-1.2 -> patched qemu.git,
nor qemu-1.2.2 -> patched qemu.git. But admittedly I don't understand the
subtleties involved in migration compat.


[1] Well, doesn't blow up any more than normal. Migrating stock qemu 1.2.2 ->
qemu.git is crashing for me:

#0  0x00007ffff24b6e50 in __memcmp_sse4_1 () from /lib64/libc.so.6
#1  0x000055555578c532 in patch_hypercalls (s=0x555556513f10)
    at /home/crobinso/qemu-clean/hw/i386/../kvmvapic.c:544
#2  vapic_prepare (s=s@entry=0x555556513f10)
    at /home/crobinso/qemu-clean/hw/i386/../kvmvapic.c:609
#3  0x000055555578c612 in vapic_post_load (opaque=0x555556513f10,
    version_id=<optimized out>)
    at /home/crobinso/qemu-clean/hw/i386/../kvmvapic.c:726
#4  0x00005555557ca0b0 in vmstate_load_state (f=f@entry=0x555556636510, vmsd=
    0x555555c0a840 <vmstate_vapic>, opaque=0x555556513f10, version_id=1)
    at /home/crobinso/qemu-clean/savevm.c:1451
#5  0x00005555557cac53 in vmstate_load (version_id=<optimized out>, se=
    0x555556520da0, f=0x555556636510)
    at /home/crobinso/qemu-clean/savevm.c:1514
#6  qemu_loadvm_state (f=f@entry=0x555556636510)
    at /home/crobinso/qemu-clean/savevm.c:1977
#7  0x00005555556fa15e in process_incoming_migration_co (opaque=0x555556636510)
    at migration.c:97
#8  0x000055555561f82a in coroutine_trampoline (i0=<optimized out>,
    i1=<optimized out>) at coroutine-ucontext.c:138
#9  0x00007ffff23a16c0 in ?? () from /lib64/libc.so.6
#10 0x00007fffffffd270 in ?? ()
#11 0x0000000000000000 in ?? ()

Using:
qemu-system-x86_64 -M pc-1.2 -sdl -net none -vga cirrus -enable-kvm -m 2048
-incoming 'exec:cat migrate-to-file.img'


Thanks,
Cole

  parent reply	other threads:[~2013-01-15  3:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12 22:39 [Qemu-devel] [PATCH] define qemukvm-1.2 machine type Marcelo Tosatti
2012-12-13  8:35 ` Paolo Bonzini
2012-12-13 20:29   ` Marcelo Tosatti
2012-12-13 21:25   ` Eduardo Habkost
2012-12-13 21:35     ` Anthony Liguori
2012-12-13 21:41       ` Eduardo Habkost
2012-12-14  7:54         ` Paolo Bonzini
2012-12-14 13:29           ` Anthony Liguori
2012-12-14 13:46             ` Paolo Bonzini
2012-12-13 21:15 ` Anthony Liguori
2013-01-15  3:45 ` Cole Robinson [this message]
2013-01-15 16:29   ` Paolo Bonzini
2013-01-16 23:17     ` Cole Robinson
2013-01-18 12:12       ` Marcelo Tosatti
2013-01-18 17:04         ` Cole Robinson
2013-01-18 17:34           ` Paolo Bonzini
2013-01-18 20:09             ` Marcelo Tosatti
2013-01-19 14:17               ` Paolo Bonzini
2013-01-18 19:50           ` Marcelo Tosatti

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=50F4D0BC.9020207@redhat.com \
    --to=crobinso@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=mtosatti@redhat.com \
    --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 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.