All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: aliguori@us.ibm.com, ehabkost@redhat.com, gleb@redhat.com,
	mtosatti@redhat.com, qemu-devel@nongnu.org,
	Orit Wasserman <owasserm@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] Fix real mode guest migration
Date: Mon, 22 Jul 2013 12:33:31 +0200	[thread overview]
Message-ID: <51ED0A7B.9030704@suse.de> (raw)
In-Reply-To: <51ED0025.7090805@redhat.com>

Am 22.07.2013 11:49, schrieb Paolo Bonzini:
> Il 22/07/2013 08:49, Orit Wasserman ha scritto:
>> Older KVM versions save CS dpl value to an invalid value for real mode guests
>> (0x3). This patch detect this situation when loading CPU state and set all the
>> segments dpl to zero.
>> This will allow migration from older KVM on host without unrestricted guest
>> to hosts with restricted guest support.
>> For example migration from a Penryn host (with kernel 2.6.32) to
>> a Westmere host.
>>
>> Signed-off-by: Orit Wasserman <owasserm@redhat.com>
>> ---
>>  target-i386/machine.c | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/target-i386/machine.c b/target-i386/machine.c
>> index 3659db9..7e95829 100644
>> --- a/target-i386/machine.c
>> +++ b/target-i386/machine.c
>> @@ -260,6 +260,24 @@ static int cpu_post_load(void *opaque, int version_id)
>>      CPUX86State *env = &cpu->env;
>>      int i;
>>  
>> +    /*
>> +      Real mode guest segments register DPL should be zero.
>> +      Older KVM version were setting it worngly.
>> +      Fixing it will allow live migration from such host that don't have
>> +      restricted guest support to an host with unrestricted guest support
>> +      (otherwise the migration will fail with invalid guest state
>> +      error).
>> +    */
> 
> Coding standard asks for *s on every line.
> 
> As discussed offlist, I would prefer to have this in the kernel since
> that's where the bug is.  Gleb disagrees.
> 
> We need to find a third person who mediates...  Anthony, Eduardo, what
> do you think?

Having the code here does not look wrong to me, to enforce a consistent
state inside QEMU.

However I wonder what happens without this patch on Westmere? Might it
make sense to sanitize or at least "assert" (whatever the kernel
equivalent is ;)) in the ioctl setting X86CPU state to the vCPU that the
incoming values will be valid for the host CPU? And optionally in QEMU's
KVM code for the reverse direction, cpu_synchronize_state(), to cope
with older kernels?

Regards,
Andreas

>> +    if (!(env->cr[0] & CR0_PE_MASK) &&
>> +         (env->segs[R_CS].flags >> DESC_DPL_SHIFT & 3) != 0) {
>> +        env->segs[R_CS].flags &= ~(env->segs[R_CS].flags & DESC_DPL_MASK);
>> +        env->segs[R_DS].flags &= ~(env->segs[R_DS].flags & DESC_DPL_MASK);
>> +        env->segs[R_ES].flags &= ~(env->segs[R_ES].flags & DESC_DPL_MASK);
>> +        env->segs[R_FS].flags &= ~(env->segs[R_FS].flags & DESC_DPL_MASK);
>> +        env->segs[R_GS].flags &= ~(env->segs[R_GS].flags & DESC_DPL_MASK);
>> +        env->segs[R_SS].flags &= ~(env->segs[R_SS].flags & DESC_DPL_MASK);
>> +    }
>> +
>>      /* XXX: restore FPU round state */
>>      env->fpstt = (env->fpus_vmstate >> 11) & 7;
>>      env->fpus = env->fpus_vmstate & ~0x3800;

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  parent reply	other threads:[~2013-07-22 10:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  6:49 [Qemu-devel] [PATCH 1/2] Fix real mode guest migration Orit Wasserman
2013-07-22  6:49 ` [Qemu-devel] [PATCH 2/2] Fix real mode guest segments dpl value in savevm Orit Wasserman
2013-07-22  9:49 ` [Qemu-devel] [PATCH 1/2] Fix real mode guest migration Paolo Bonzini
2013-07-22  9:58   ` Gleb Natapov
2013-07-22 10:10   ` Orit Wasserman
2013-07-22 10:14     ` Paolo Bonzini
2013-07-22 13:20       ` Eduardo Habkost
2013-07-22 10:33   ` Andreas Färber [this message]
2013-07-22 10:50     ` Gleb Natapov
2013-07-22 10:59     ` Orit Wasserman
2013-07-22 12:46       ` Juan Quintela
2013-07-22 17:50   ` Anthony Liguori
2013-07-22 18:50     ` Gleb Natapov
2013-07-22 10:50 ` Juan Quintela
2013-07-22 16:37 ` Eric Blake

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=51ED0A7B.9030704@suse.de \
    --to=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=gleb@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=owasserm@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.