qemu-devel.nongnu.org archive mirror
 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 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).