From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [PATCH] KVM: x86: allow RSM from 64-bit mode Date: Tue, 3 Nov 2015 19:27:09 +0100 Message-ID: <5638FC7D.9060807@redhat.com> References: <1446557368-9278-1-git-send-email-pbonzini@redhat.com> <5638B94A.2090702@redhat.com> <5638BAC7.2030704@redhat.com> <5638BE58.6060507@redhat.com> <5638BEFA.30907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: stable@vger.kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Return-path: In-Reply-To: <5638BEFA.30907@redhat.com> Sender: stable-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 11/03/15 15:04, Paolo Bonzini wrote: >=20 >=20 > On 03/11/2015 15:02, Laszlo Ersek wrote: >> On 11/03/15 14:46, Paolo Bonzini wrote: >>> >>> >>> On 03/11/2015 14:40, Laszlo Ersek wrote: >>>> On 11/03/15 14:29, Paolo Bonzini wrote: >>>>> The SDM says that exiting system management mode from 64-bit mode >>>>> is invalid, but that would be too good to be true. But actually, >>>>> most of the code is already there to support exiting from compat >>>>> mode (EFER.LME=3D1, EFER.LMA=3D0). Getting all the way from 64-b= it >>>>> mode to real mode only requires clearing CS.L and CR4.PCIDE. >>>>> >>>>> Cc: stable@vger.kernel.org >>>>> Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c >>>>> Cc: Laszlo Ersek >>>>> Cc: Radim Kr=C4=8Dm=C3=A1=C5=99 >>>>> Signed-off-by: Paolo Bonzini >>>>> --- >>>>> arch/x86/kvm/emulate.c | 30 +++++++++++++++++++++++++----- >>>>> 1 file changed, 25 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >>>>> index b60fed56671b..1505587d06e9 100644 >>>>> --- a/arch/x86/kvm/emulate.c >>>>> +++ b/arch/x86/kvm/emulate.c >>>>> @@ -2484,16 +2484,36 @@ static int em_rsm(struct x86_emulate_ctxt= *ctxt) >>>>> =20 >>>>> /* >>>>> * Get back to real mode, to prepare a safe state in which to l= oad >>>>> - * CR0/CR3/CR4/EFER. >>>>> - * >>>>> - * CR4.PCIDE must be zero, because it is a 64-bit mode only fea= ture. >>>>> + * CR0/CR3/CR4/EFER. It's all a bit more complicated if the vC= PU >>>>> + * supports long mode. >>>>> */ >>>>> + cr4 =3D ctxt->ops->get_cr(ctxt, 4); >>>>> + if (emulator_has_longmode(ctxt)) { >>>>> + struct desc_struct cs_desc; >>>>> + >>>>> + /* Zero CR4.PCIDE before CR0.PG. */ >>>>> + if (cr4 & X86_CR4_PCIDE) { >>>>> + ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PCIDE); >>>>> + cr4 &=3D ~X86_CR4_PCIDE; >>>>> + } >>>>> + >>>>> + /* A 32-bit code segment is required to clear EFER.LMA. */ >>>>> + memset(&cs_desc, 0, sizeof(cs_desc)); >>>>> + cs_desc.type =3D 0xb; >>>>> + cs_desc.s =3D cs_desc.g =3D cs_desc.p =3D 1; >>>>> + ctxt->ops->set_segment(ctxt, 0, &cs_desc, 0, VCPU_SREG_CS); >>>>> + } >>>>> + >>>>> + /* For the 64-bit case, this will clear EFER.LMA. */ >>>>> cr0 =3D ctxt->ops->get_cr(ctxt, 0); >>>>> if (cr0 & X86_CR0_PE) >>>>> ctxt->ops->set_cr(ctxt, 0, cr0 & ~(X86_CR0_PG | X86_CR0_PE)); >>>>> - cr4 =3D ctxt->ops->get_cr(ctxt, 4); >>>>> + >>>>> + /* Now clear CR4.PAE (which must be done before clearing EFER.L= ME). */ >>>>> if (cr4 & X86_CR4_PAE) >>>>> ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE); >>>>> + >>>>> + /* And finally go back to 32-bit mode. */ >>>>> efer =3D 0; >>>>> ctxt->ops->set_msr(ctxt, MSR_EFER, efer); >>>>> =20 >>>>> @@ -4454,7 +4474,7 @@ static const struct opcode twobyte_table[25= 6] =3D { >>>>> F(DstMem | SrcReg | Src2CL | ModRM, em_shld), N, N, >>>>> /* 0xA8 - 0xAF */ >>>>> I(Stack | Src2GS, em_push_sreg), I(Stack | Src2GS, em_pop_sreg)= , >>>>> - II(No64 | EmulateOnUD | ImplicitOps, em_rsm, rsm), >>>>> + II(EmulateOnUD | ImplicitOps, em_rsm, rsm), >>>>> F(DstMem | SrcReg | ModRM | BitOp | Lock | PageTable, em_bts), >>>>> F(DstMem | SrcReg | Src2ImmByte | ModRM, em_shrd), >>>>> F(DstMem | SrcReg | Src2CL | ModRM, em_shrd), >>>>> >>>> >>>> What branch should I test this on top of? >>> >>> Just use whatever you were using before, and revert commit c9db607 >>> ("UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode", >>> 2015-10-14) from your OVMF branch. >> >> Right, I planned to do that OVMF-side revert; I just wasn't sure if = e.g. >> kvm/queue had some prerequisite patches for this. >=20 > Indeed, you can use either your "part 2" series or Radim's patches fr= om > kvm/queue, it's the same. I noticed that you applied this patch to kvm/queue, at 9f64d2c75fa6a5aac0a5657400f3473f8144c3be. So I simply tested kvm/queue in that state. (I did not forget to drop the workaround OVMF patch firs= t.) Tested-by: Laszlo Ersek Thank you! Laszlo