From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BCEBC4167B for ; Wed, 6 Dec 2023 16:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379170AbjLFQVY (ORCPT ); Wed, 6 Dec 2023 11:21:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378358AbjLFQVW (ORCPT ); Wed, 6 Dec 2023 11:21:22 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87B15137 for ; Wed, 6 Dec 2023 08:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701879687; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yBHnmpTdUAAABbA8Mh1bA1BUO5b6J3rmpt1I3QMnK5Y=; b=UxanHiNTbzy4nPMODrecvVCgc+jk4/EjOXiBX4CxvKLiOCBewsOc+EmpDmYKa0w0Epzdum VfJ5CRsOZGXNQ6rxSIm+prXd75e6YyNJlrOQGxQSZdiubItQKYqBvgFh8vqcOWXPkvsut5 JSWEkT3mbLYgAFmfT35/L9FVCuMzHiw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-684-g3UG8CpbMQCzNgF25pU3Aw-1; Wed, 06 Dec 2023 11:21:26 -0500 X-MC-Unique: g3UG8CpbMQCzNgF25pU3Aw-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-40b39377136so52518535e9.1 for ; Wed, 06 Dec 2023 08:21:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701879685; x=1702484485; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yBHnmpTdUAAABbA8Mh1bA1BUO5b6J3rmpt1I3QMnK5Y=; b=hfL52w4fY1wGloFCgZna0b3iFsT/1nmp9SUs6jaHDm3irwbnG/b97S6h2VivVjeEql bkg3N77E2BmuxKc1p/78Qym0hyvcMPCfC+1OhHiIWsIcz8/GQvQei4Pzk87JbFvQX+kN DuE3C17XKXsMe/2MSNlf83VU1c0iqIarbTbMv+xUm7n1roZMnHtFMOEH4cMgqyPS9XMO 9jxqZvzRxZ5DU/SlLR/kGL7aeQMC2sMATOzBkzZtfCFCtZ/LkelALiJBpcj2b42nPcNc aVvmLO8TVTfOknoy5YDY/RtCq6kewXUMOqdwZi6Wv9x0qd65ahFjyA8WngmkXdGesgwu lTEg== X-Gm-Message-State: AOJu0Yw8gZEsZeeLlstLtUnHyD+PoXXx7RBnv6CG8acCI+DVlBGlCfV5 yVPMU1y0dkB7z9u4yuO9CXR0mc42BWYL71pdJwW5feQQ0UJWySdS+qA0R8/0Uekqgc0GqWBPqXI SiMLhW8bAU0mAiSEChSyNHLHc X-Received: by 2002:a05:600c:354f:b0:401:bd2e:49fc with SMTP id i15-20020a05600c354f00b00401bd2e49fcmr754494wmq.24.1701879685207; Wed, 06 Dec 2023 08:21:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHHWRueBGFjuqH7LTjLrUPFBWtdG2OWtYQEqZHufXz0GKcVxX4ZdL32r3Rlza5w9bs0UKjXVA== X-Received: by 2002:a05:600c:354f:b0:401:bd2e:49fc with SMTP id i15-20020a05600c354f00b00401bd2e49fcmr754477wmq.24.1701879684841; Wed, 06 Dec 2023 08:21:24 -0800 (PST) Received: from starship ([89.237.98.20]) by smtp.gmail.com with ESMTPSA id fj5-20020a05600c0c8500b0040b2b38a1fasm101981wmb.4.2023.12.06.08.21.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Dec 2023 08:21:24 -0800 (PST) Message-ID: <3e5a23c106ae5e86eba05391d1cba3f0b9c3854d.camel@redhat.com> Subject: Re: [PATCH] KVM: SEV: Fix handling of EFER_LMA bit when SEV-ES is enabled From: Maxim Levitsky To: Michael Roth , kvm@vger.kernel.org Cc: Tom Lendacky , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Date: Wed, 06 Dec 2023 18:21:22 +0200 In-Reply-To: <20231205234956.1156210-1-michael.roth@amd.com> References: <20231205234956.1156210-1-michael.roth@amd.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2023-12-05 at 17:49 -0600, Michael Roth wrote: > In general, activating long mode involves setting the EFER_LME bit in > the EFER register and then enabling the X86_CR0_PG bit in the CR0 > register. At this point, the EFER_LMA bit will be set automatically by > hardware. > > In the case of SVM/SEV guests where writes to CR0 are intercepted, it's > necessary for the host to set EFER_LMA on behalf of the guest since > hardware does not see the actual CR0 write. Could you explain in which case the writes to CR0 will be still intercepted? It's for CPUs that only support SEV-ES and nothing beyond it? > > In the case of SEV-ES guests where writes to CR0 are trapped instead of > intercepted, the hardware *does* see/record the write to CR0 before > exiting and passing the value on to the host, so as part of enabling > SEV-ES support commit f1c6366e3043 ("KVM: SVM: Add required changes to > support intercepts under SEV-ES") dropped special handling of the > EFER_LMA bit with the understanding that it would be set automatically. > > However, since the guest never explicitly sets the EFER_LMA bit, the > host never becomes aware that it has been set. This becomes problematic > when userspace tries to get/set the EFER values via > KVM_GET_SREGS/KVM_SET_SREGS, since the EFER contents tracked by the host > will be missing the EFER_LMA bit, and when userspace attempts to pass > the EFER value back via KVM_SET_SREGS it will fail a sanity check that > asserts that EFER_LMA should always be set when X86_CR0_PG and EFER_LME > are set. > > Fix this by always inferring the value of EFER_LMA based on X86_CR0_PG > and EFER_LME, regardless of whether or not SEV-ES is enabled. > > Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts under SEV-ES") > Suggested-by: Tom Lendacky > Cc: Sean Christopherson > Cc: Paolo Bonzini > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: "H. Peter Anvin" > Cc: Tom Lendacky > Cc: x86@kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Michael Roth > --- > arch/x86/kvm/svm/svm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 5d75a1732da4..b31d4f2deb66 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -1869,7 +1869,7 @@ void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) > bool old_paging = is_paging(vcpu); > > #ifdef CONFIG_X86_64 > - if (vcpu->arch.efer & EFER_LME && !vcpu->arch.guest_state_protected) { > + if (vcpu->arch.efer & EFER_LME) { > if (!is_paging(vcpu) && (cr0 & X86_CR0_PG)) { > vcpu->arch.efer |= EFER_LMA; > svm->vmcb->save.efer |= EFER_LMA | EFER_LME; Purely from the point of view of not confusing future readers of this code: Due to encrypted guest state, if I understand correctly, the 'svm->vmcb->save.efer' is only given for the hypervisor to see but not to modify. While the modification of save.efer is a nop, can we still guard it with 'vcpu->arch.guest_state_protected'? Besides these nitpicks: Reviewed-by: Maxim Levitsky Best regards, Maxim Levitsky