From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1FVz-0000PF-Ic for qemu-devel@nongnu.org; Mon, 22 Jul 2013 08:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1FVy-00048u-Gz for qemu-devel@nongnu.org; Mon, 22 Jul 2013 08:46:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1FVy-00048l-9Y for qemu-devel@nongnu.org; Mon, 22 Jul 2013 08:46:58 -0400 From: Juan Quintela In-Reply-To: <51ED10A2.6050700@redhat.com> (Orit Wasserman's message of "Mon, 22 Jul 2013 13:59:46 +0300") References: <1374475799-18523-1-git-send-email-owasserm@redhat.com> <51ED0025.7090805@redhat.com> <51ED0A7B.9030704@suse.de> <51ED10A2.6050700@redhat.com> Date: Mon, 22 Jul 2013 14:46:45 +0200 Message-ID: <87y58yrccq.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] Fix real mode guest migration Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Orit Wasserman Cc: aliguori@us.ibm.com, ehabkost@redhat.com, gleb@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Andreas =?utf-8?Q?F=C3=A4rber?= Orit Wasserman wrote: > On 07/22/2013 01:33 PM, Andreas F=C3=A4rber wrote: >> 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 >>>> --- >>>> 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 versio= n_id) >>>> CPUX86State *env =3D &cpu->env; >>>> int i; >>>>=20=20 >>>> + /* >>>> + 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 h= ave >>>> + restricted guest support to an host with unrestricted guest sup= port >>>> + (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? >>=20 >> Having the code here does not look wrong to me, to enforce a consistent >> state inside QEMU. >>=20 >> 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? >>=20 > > Without the patch we get "kvm: unhandled exit 80000021" error in incoming > migration or loadvm. This is a KVM error (kernel) which translates to inv= alid > guest state.This happens only in migration of a real mode guest. > > The problem in fixing the values in cpu_synchronize_state is that the fun= ction > is called in many places in the code.=20 > As real mode code is very complex (Gleb can attest to that) I prefer a fi= x that > has a very limited scope like fixing it in the cpu_post_load and cpu_pre_= save > function that are only used in savevm and live migration. I fully agree with this approach. So far, the problem only happens with migration. This fix the case if we have new qemu. If we have old qemu, we got the same problem that we had before. And as Gleb said, checking for all possible problems on kvm is imposible, as they are too many, and we would break abi. So, I preffer this approach, for what is worth. Later, Juan.