Message ID | 20221117143242.102721-8-mlevitsk@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp433624wrr; Thu, 17 Nov 2022 06:36:00 -0800 (PST) X-Google-Smtp-Source: AA0mqf4fxNTL5QHmS7ey8Xc9VgIcbwXcVS4OUBeTyi656kRyc1feqsH2fjqVdZ3AFF7W3RoZOIFs X-Received: by 2002:a17:90a:b38b:b0:214:1328:ac8f with SMTP id e11-20020a17090ab38b00b002141328ac8fmr3041722pjr.198.1668695759906; Thu, 17 Nov 2022 06:35:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668695759; cv=none; d=google.com; s=arc-20160816; b=zqSI0pBDDA6hjN5xzDfB7ovaG8OwqPICmb78mNskmCdXopWWMw5jMNsjXEt56Mx7LM 5oUAdaKaXgUd6Iz1KxsgtDGNhByKQ5v9o57QOOToDka4FST6Zggh61eQRauebP/qqx+x sJUrp020tIqg4h0+n6GY1Nm30o5tCYudpo1eT29HCyDOvjElTLTj8ILWVp/D/z+Q2R0k 1clCu9IXg3sghaKX+Raq15z8TfFlpeHHViWMhLZ1DgCgVSF9pFc/ZcAQ/UMZhWuu4sSf FBnrSBE7APCd2t0wJo429Stdx1FPtionjgmvlOPwef+72824ANAyxfOkxxWh1UyvGcZh sI5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ps9mGB4FWMNZUhRI7eqw38JkpYxzOMfFPzgwHnz9dQU=; b=iWGKWPAS/q/uMFs+ngegIPtpZLn3RJaTdL7WI5oJrOWDXyYRx95OZWiDW5s9At+pYn aGdrI5xiUXB4f0zT6mj8Q7w0EhC54uYJf5FkF3OFq2nzMRWYTeB4mZf2Ew/GXx6xKiYf retokmBAPBiTwMUHmo2MMMKWo6kq5qQwj7gztlLsNJCndYeVOW0unKRQN4Mk1ZBhhzRo LD4NoUP2xFzlmzWe1bslVAC1R66XWR2eNgU9B0VtDmrsa4FRJ/mtymGZp0ue7Wyc2Tqo SdNP1NTI0r5YUaSDlBd0pb7k7XGH2w2DcRHP/+c8q6Zkx9Qawktdw04TeKbNK4xWjoTF K+gQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KKoU00Al; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j17-20020a63fc11000000b004630aa449c2si1133603pgi.242.2022.11.17.06.35.47; Thu, 17 Nov 2022 06:35:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KKoU00Al; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239889AbiKQOex (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Thu, 17 Nov 2022 09:34:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234834AbiKQOeV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 17 Nov 2022 09:34:21 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58E4179E34 for <linux-kernel@vger.kernel.org>; Thu, 17 Nov 2022 06:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668695600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ps9mGB4FWMNZUhRI7eqw38JkpYxzOMfFPzgwHnz9dQU=; b=KKoU00AlzaPWOQCHsMmuMBuvaIRJyoWPiTkQKnItjZhglBcboKvePoW2bpWFcbqE7cjIUG 6IXhPq2E8Y30gLMtegb6neKVqXAliSEO0C98ZHGxsDpDrenh7cGTPwhVJG6vslJ+lTKpqM BCLk2Iva9JfW+eMymhbV1G+rF20ECkQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-389-Jy4x4LlPPDyb9i2N1ngPYQ-1; Thu, 17 Nov 2022 09:33:14 -0500 X-MC-Unique: Jy4x4LlPPDyb9i2N1ngPYQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62DAC1C08978; Thu, 17 Nov 2022 14:33:13 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id DAF482166B29; Thu, 17 Nov 2022 14:33:09 +0000 (UTC) From: Maxim Levitsky <mlevitsk@redhat.com> To: kvm@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Dave Hansen <dave.hansen@linux.intel.com>, linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Sandipan Das <sandipan.das@amd.com>, Daniel Sneddon <daniel.sneddon@linux.intel.com>, Jing Liu <jing2.liu@intel.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Wyes Karny <wyes.karny@amd.com>, Borislav Petkov <bp@alien8.de>, Babu Moger <babu.moger@amd.com>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Sean Christopherson <seanjc@google.com>, Jim Mattson <jmattson@google.com>, x86@kernel.org, Maxim Levitsky <mlevitsk@redhat.com>, Santosh Shukla <santosh.shukla@amd.com> Subject: [PATCH 07/13] KVM: SVM: Add VNMI support in get/set_nmi_mask Date: Thu, 17 Nov 2022 16:32:36 +0200 Message-Id: <20221117143242.102721-8-mlevitsk@redhat.com> In-Reply-To: <20221117143242.102721-1-mlevitsk@redhat.com> References: <20221117143242.102721-1-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749754325425543187?= X-GMAIL-MSGID: =?utf-8?q?1749754325425543187?= |
Series |
SVM: vNMI (with my fixes)
|
|
Commit Message
Maxim Levitsky
Nov. 17, 2022, 2:32 p.m. UTC
From: Santosh Shukla <santosh.shukla@amd.com> VMCB intr_ctrl bit12 (V_NMI_MASK) is set by the processor when handling NMI in guest and is cleared after the NMI is handled. Treat V_NMI_MASK as read-only in the hypervisor except for the SMM case where hypervisor before entring and after leaving SMM mode requires to set and unset V_NMI_MASK. Adding API(get_vnmi_vmcb) in order to return the correct vmcb for L1 or L2. Maxim: - made set_vnmi_mask/clear_vnmi_mask/is_vnmi_mask warn if called without vNMI enabled - clear IRET intercept in svm_set_nmi_mask even with vNMI Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> --- arch/x86/kvm/svm/svm.c | 18 ++++++++++++++- arch/x86/kvm/svm/svm.h | 52 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+), 1 deletion(-)
Comments
On Thu, Nov 17, 2022, Maxim Levitsky wrote: > From: Santosh Shukla <santosh.shukla@amd.com> > > VMCB intr_ctrl bit12 (V_NMI_MASK) is set by the processor when handling > NMI in guest and is cleared after the NMI is handled. Treat V_NMI_MASK > as read-only in the hypervisor except for the SMM case where hypervisor > before entring and after leaving SMM mode requires to set and unset > V_NMI_MASK. > > Adding API(get_vnmi_vmcb) in order to return the correct vmcb for L1 or > L2. > > Maxim: > - made set_vnmi_mask/clear_vnmi_mask/is_vnmi_mask warn if called > without vNMI enabled > - clear IRET intercept in svm_set_nmi_mask even with vNMI > > Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > --- > arch/x86/kvm/svm/svm.c | 18 ++++++++++++++- > arch/x86/kvm/svm/svm.h | 52 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 69 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 08a7b2a0a29f3a..c16f68f6c4f7d7 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -3618,13 +3618,29 @@ static int svm_nmi_allowed(struct kvm_vcpu *vcpu, bool for_injection) > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > { > - return !!(vcpu->arch.hflags & HF_NMI_MASK); > + struct vcpu_svm *svm = to_svm(vcpu); > + > + if (is_vnmi_enabled(svm)) > + return is_vnmi_mask_set(svm); > + else > + return !!(vcpu->arch.hflags & HF_NMI_MASK); > } > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > { > struct vcpu_svm *svm = to_svm(vcpu); > > + if (is_vnmi_enabled(svm)) { > + if (masked) > + set_vnmi_mask(svm); I believe not setting INTERCEPT_IRET is correct, but only because the existing code is unnecessary. And this all very subtly relies on KVM_REQ_EVENT being set and/or KVM already being in kvm_check_and_inject_events(). When NMIs become unblocked, INTERCEPT_IRET can be cleared, but KVM should also pending KVM_REQ_EVENT. AFAICT, that doesn't happen when this is called via the emulator. Ah, because em_iret() only handles RM for Intel's restricted guest crap. I.e. it "works" only because it never happens. All other flows set KVM_REQ_EVENT when toggling NMI blocking, e.g. the RSM path of kvm_smm_changed(). And when NMIs become blocked, there's no need to force INTERCEPT_IRET in this code because kvm_check_and_inject_events() will request an NMI window and set the intercept if necessary, and all paths that set NMI blocking are guaranteed to reach kvm_check_and_inject_events() before entering the guest. 1. RSM => kvm_smm_changed() sets KVM_REQ_EVENT 2. enter_smm() is only called from within kvm_check_and_inject_events(), before pending NMIs are processed (yay priority) 3. emulator_set_nmi_mask() never blocks NMIs, only does the half-baked IRET emulation 4. kvm_vcpu_ioctl_x86_set_vcpu_event() sets KVM_REQ_EVENT So, can you add a prep patch to drop the forced INTERCEPT_IRET? That way the logic for vNMI and !vNMI is the same. > + else { > + clear_vnmi_mask(svm); This is the only code that sets/clears the vNMI mask, so rather than have set/clear helpers, what about a single helper to do the dirty work? > + if (!sev_es_guest(vcpu->kvm)) > + svm_clr_intercept(svm, INTERCEPT_IRET); > + } > + return; > + } > + > if (masked) { > vcpu->arch.hflags |= HF_NMI_MASK; > if (!sev_es_guest(vcpu->kvm)) > diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h > index f5383104d00580..bf7f4851dee204 100644 > --- a/arch/x86/kvm/svm/svm.h > +++ b/arch/x86/kvm/svm/svm.h > @@ -35,6 +35,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly; > extern bool npt_enabled; > extern int vgif; > extern bool intercept_smi; > +extern bool vnmi; > > enum avic_modes { > AVIC_MODE_NONE = 0, > @@ -531,6 +532,57 @@ static inline bool is_x2apic_msrpm_offset(u32 offset) > (msr < (APIC_BASE_MSR + 0x100)); > } > > +static inline struct vmcb *get_vnmi_vmcb(struct vcpu_svm *svm) > +{ > + if (!vnmi) > + return NULL; > + > + if (is_guest_mode(&svm->vcpu)) > + return svm->nested.vmcb02.ptr; > + else > + return svm->vmcb01.ptr; > +} > + > +static inline bool is_vnmi_enabled(struct vcpu_svm *svm) > +{ > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > + > + if (vmcb) > + return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > + else > + return false; Maybe just this? return vmcb && (vmcb->control.int_ctl & V_NMI_ENABLE); Or if an inner helper is added: return vmcb && __is_vnmi_enabled(vmcb); > +} > + > +static inline bool is_vnmi_mask_set(struct vcpu_svm *svm) > +{ > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > + > + if (!WARN_ON_ONCE(!vmcb)) Rather than WARN, add an inner __is_vnmi_enabled() that takes the vnmi_vmcb. Actually, if you do that, the test/set/clear helpers can go away entirely. > + return false; > + > + return !!(vmcb->control.int_ctl & V_NMI_MASK); > +} > + > +static inline void set_vnmi_mask(struct vcpu_svm *svm) > +{ > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > + > + if (!WARN_ON_ONCE(!vmcb)) > + return; > + > + vmcb->control.int_ctl |= V_NMI_MASK; > +} > + > +static inline void clear_vnmi_mask(struct vcpu_svm *svm) > +{ > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > + > + if (!WARN_ON_ONCE(!vmcb)) > + return; > + > + vmcb->control.int_ctl &= ~V_NMI_MASK; > +} These helpers can all go in svm. There are no users oustide of svm.c, and unless I'm misunderstanding how nested works, there should never be oustide users. E.g. with HF_NMI_MASK => svm->nmi_masked, the end result can be something like: static bool __is_vnmi_enabled(struct *vmcb) { return !!(vmcb->control.int_ctl & V_NMI_ENABLE); } static bool is_vnmi_enabled(struct vcpu_svm *svm) { struct vmcb *vmcb = get_vnmi_vmcb(svm); return vmcb && __is_vnmi_enabled(vmcb); } static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm = to_svm(vcpu); struct vmcb *vmcb = get_vnmi_vmcb(svm); if (vmcb && __is_vnmi_enabled(vmcb)) return !!(vmcb->control.int_ctl & V_NMI_MASK); else return !!(vcpu->arch.hflags & HF_NMI_MASK); } static void svm_set_or_clear_vnmi_mask(struct vmcb *vmcb, bool set) { if (set) vmcb->control.int_ctl |= V_NMI_MASK; else vmcb->control.int_ctl &= ~V_NMI_MASK; } static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) { struct vcpu_svm *svm = to_svm(vcpu); struct vmcb *vmcb = get_vnmi_vmcb(svm); if (vmcb && __is_vnmi_enabled(vmcb)) { if (masked) vmcb->control.int_ctl |= V_NMI_MASK; else vmcb->control.int_ctl &= ~V_NMI_MASK; } else { svm->nmi_masked = masked; } if (!masked) svm_disable_iret_interception(svm); }
On Thu, 2022-11-17 at 18:54 +0000, Sean Christopherson wrote: > On Thu, Nov 17, 2022, Maxim Levitsky wrote: > > From: Santosh Shukla <santosh.shukla@amd.com> > > > > VMCB intr_ctrl bit12 (V_NMI_MASK) is set by the processor when handling > > NMI in guest and is cleared after the NMI is handled. Treat V_NMI_MASK > > as read-only in the hypervisor except for the SMM case where hypervisor > > before entring and after leaving SMM mode requires to set and unset > > V_NMI_MASK. > > > > Adding API(get_vnmi_vmcb) in order to return the correct vmcb for L1 or > > L2. > > > > Maxim: > > - made set_vnmi_mask/clear_vnmi_mask/is_vnmi_mask warn if called > > without vNMI enabled > > - clear IRET intercept in svm_set_nmi_mask even with vNMI > > > > Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > --- > > arch/x86/kvm/svm/svm.c | 18 ++++++++++++++- > > arch/x86/kvm/svm/svm.h | 52 ++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 69 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > index 08a7b2a0a29f3a..c16f68f6c4f7d7 100644 > > --- a/arch/x86/kvm/svm/svm.c > > +++ b/arch/x86/kvm/svm/svm.c > > @@ -3618,13 +3618,29 @@ static int svm_nmi_allowed(struct kvm_vcpu *vcpu, bool for_injection) > > > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > > { > > - return !!(vcpu->arch.hflags & HF_NMI_MASK); > > + struct vcpu_svm *svm = to_svm(vcpu); > > + > > + if (is_vnmi_enabled(svm)) > > + return is_vnmi_mask_set(svm); > > + else > > + return !!(vcpu->arch.hflags & HF_NMI_MASK); > > } > > > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > > { > > struct vcpu_svm *svm = to_svm(vcpu); > > > > + if (is_vnmi_enabled(svm)) { > > + if (masked) > > + set_vnmi_mask(svm); > > I believe not setting INTERCEPT_IRET is correct, but only because the existing > code is unnecessary. And this all very subtly relies on KVM_REQ_EVENT being set > and/or KVM already being in kvm_check_and_inject_events(). > > When NMIs become unblocked, INTERCEPT_IRET can be cleared, but KVM should also > pending KVM_REQ_EVENT. AFAICT, that doesn't happen when this is called via the > emulator. Ah, because em_iret() only handles RM for Intel's restricted guest > crap. I.e. it "works" only because it never happens. All other flows set > KVM_REQ_EVENT when toggling NMI blocking, e.g. the RSM path of kvm_smm_changed(). Makes sense > > And when NMIs become blocked, there's no need to force INTERCEPT_IRET in this > code because kvm_check_and_inject_events() will request an NMI window and set the > intercept if necessary, and all paths that set NMI blocking are guaranteed to > reach kvm_check_and_inject_events() before entering the guest. I think I understand what you mean. When a normal NMI is injected, we do have to intercept IRET because this is how we know that NMI done executing. But if NMI becames masked then it can be either if: 1. We are already in NMI, so masking it is essintially NOP, so no need to intercept IRET since it is already intercepted. 2. We are not in NMI, then we don't need to intercept IRET, since its interception is not needed to track that NMI is over, but only needed to detect NMI window (IRET can be used without a paired NMI to unblock NMIs, which is IMHO a very wrong x86 design decision, but the ship sailed long ago), and so we can intercept IRET only when we request an actual NMI window. Makes sense and I'll send a patch to do it. > > 1. RSM => kvm_smm_changed() sets KVM_REQ_EVENT > 2. enter_smm() is only called from within kvm_check_and_inject_events(), > before pending NMIs are processed (yay priority) > 3. emulator_set_nmi_mask() never blocks NMIs, only does the half-baked IRET emulation > 4. kvm_vcpu_ioctl_x86_set_vcpu_event() sets KVM_REQ_EVENT > > So, can you add a prep patch to drop the forced INTERCEPT_IRET? That way the > logic for vNMI and !vNMI is the same. > > > + else { > > + clear_vnmi_mask(svm); > > This is the only code that sets/clears the vNMI mask, so rather than have set/clear > helpers, what about a single helper to do the dirty work? Or not have any hepler at all maybe, since it is only done once? I don't know I just wanted to not change the original patches too much, I only changed the minimum to make it work. > > > + if (!sev_es_guest(vcpu->kvm)) > > + svm_clr_intercept(svm, INTERCEPT_IRET); > > + } > > + return; > > + } > > + > > if (masked) { > > vcpu->arch.hflags |= HF_NMI_MASK; > > if (!sev_es_guest(vcpu->kvm)) > > diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h > > index f5383104d00580..bf7f4851dee204 100644 > > --- a/arch/x86/kvm/svm/svm.h > > +++ b/arch/x86/kvm/svm/svm.h > > @@ -35,6 +35,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly; > > extern bool npt_enabled; > > extern int vgif; > > extern bool intercept_smi; > > +extern bool vnmi; > > > > enum avic_modes { > > AVIC_MODE_NONE = 0, > > @@ -531,6 +532,57 @@ static inline bool is_x2apic_msrpm_offset(u32 offset) > > (msr < (APIC_BASE_MSR + 0x100)); > > } > > > > +static inline struct vmcb *get_vnmi_vmcb(struct vcpu_svm *svm) > > +{ > > + if (!vnmi) > > + return NULL; > > + > > + if (is_guest_mode(&svm->vcpu)) > > + return svm->nested.vmcb02.ptr; > > + else > > + return svm->vmcb01.ptr; > > +} > > + > > +static inline bool is_vnmi_enabled(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (vmcb) > > + return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > > + else > > + return false; > > Maybe just this? > > return vmcb && (vmcb->control.int_ctl & V_NMI_ENABLE); > > Or if an inner helper is added: > > return vmcb && __is_vnmi_enabled(vmcb); > > > +} > > + > > +static inline bool is_vnmi_mask_set(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > Rather than WARN, add an inner __is_vnmi_enabled() that takes the vnmi_vmcb. > Actually, if you do that, the test/set/clear helpers can go away entirely. > > > + return false; > > + > > + return !!(vmcb->control.int_ctl & V_NMI_MASK); > > +} > > + > > +static inline void set_vnmi_mask(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > + return; > > + > > + vmcb->control.int_ctl |= V_NMI_MASK; > > +} > > + > > +static inline void clear_vnmi_mask(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > + return; > > + > > + vmcb->control.int_ctl &= ~V_NMI_MASK; > > +} > > These helpers can all go in svm. There are no users oustide of svm.c, and > unless I'm misunderstanding how nested works, there should never be oustide users. > > E.g. with HF_NMI_MASK => svm->nmi_masked, the end result can be something like: > > static bool __is_vnmi_enabled(struct *vmcb) > { > return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > } > > static bool is_vnmi_enabled(struct vcpu_svm *svm) > { > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > return vmcb && __is_vnmi_enabled(vmcb); > } > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > if (vmcb && __is_vnmi_enabled(vmcb)) > return !!(vmcb->control.int_ctl & V_NMI_MASK); > else > return !!(vcpu->arch.hflags & HF_NMI_MASK); > } > > static void svm_set_or_clear_vnmi_mask(struct vmcb *vmcb, bool set) > { > if (set) > vmcb->control.int_ctl |= V_NMI_MASK; > else > vmcb->control.int_ctl &= ~V_NMI_MASK; > } > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > { > struct vcpu_svm *svm = to_svm(vcpu); > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > if (vmcb && __is_vnmi_enabled(vmcb)) { > if (masked) > vmcb->control.int_ctl |= V_NMI_MASK; > else > vmcb->control.int_ctl &= ~V_NMI_MASK; > } else { > svm->nmi_masked = masked; > } > > if (!masked) > svm_disable_iret_interception(svm); > } OK, this is one of the ways to do it, makes sense overall. I actualy wanted to do something like that but opted to not touch the original code too much, but only what I needed. I can do this in a next version. Best regards, Maxim Levitsky >
On Mon, Nov 21, 2022, Maxim Levitsky wrote: > On Thu, 2022-11-17 at 18:54 +0000, Sean Christopherson wrote: > > E.g. with HF_NMI_MASK => svm->nmi_masked, the end result can be something like: > > > > static bool __is_vnmi_enabled(struct *vmcb) > > { > > return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > > } > > > > static bool is_vnmi_enabled(struct vcpu_svm *svm) > > { > > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > > > return vmcb && __is_vnmi_enabled(vmcb); > > } > > > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > > { > > struct vcpu_svm *svm = to_svm(vcpu); > > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > > > if (vmcb && __is_vnmi_enabled(vmcb)) > > return !!(vmcb->control.int_ctl & V_NMI_MASK); > > else > > return !!(vcpu->arch.hflags & HF_NMI_MASK); > > } > > > > static void svm_set_or_clear_vnmi_mask(struct vmcb *vmcb, bool set) > > { > > if (set) > > vmcb->control.int_ctl |= V_NMI_MASK; > > else > > vmcb->control.int_ctl &= ~V_NMI_MASK; > > } > > > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > > { > > struct vcpu_svm *svm = to_svm(vcpu); > > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > > > if (vmcb && __is_vnmi_enabled(vmcb)) { > > if (masked) > > vmcb->control.int_ctl |= V_NMI_MASK; > > else > > vmcb->control.int_ctl &= ~V_NMI_MASK; > > } else { > > svm->nmi_masked = masked; > > } > > > > if (!masked) > > svm_disable_iret_interception(svm); > > } > > OK, this is one of the ways to do it, makes sense overall. > I actualy wanted to do something like that but opted to not touch > the original code too much, but only what I needed. I can do this > in a next version. After looking at more of this code, I think having get_vnmi_vmcb() is a mistake. It just ends up being a funky wrapper to the current svm->vmcb. And the manual check on the "vnmi" global is pointless. If KVM sets V_NMI_ENABLE in any VMCB when vnmi=false, then that's a KVM bug. Dropping the wrapper eliminates the possibility of a NULL VMCB pointer, and IMO yields far more readable code. static bool is_vnmi_enabled(struct vcpu_svm *svm) { return !!(svm->vmcb->control.int_ctl & V_NMI_ENABLE); } static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm = to_svm(vcpu); if (is_vnmi_enabled(svm)) return !!(svm->vmcb->control.int_ctl & V_NMI_MASK); else return !!(vcpu->arch.hflags & HF_NMI_MASK); } static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) { struct vcpu_svm *svm = to_svm(vcpu); if (is_vnmi_enabled(svm)) { if (masked) svm->vmcb->control.int_ctl |= V_NMI_MASK; else svm->vmcb->control.int_ctl &= ~V_NMI_MASK; } else { svm->nmi_masked = masked; } if (!masked) svm_disable_iret_interception(svm); }
On Thu, 2022-11-17 at 18:54 +0000, Sean Christopherson wrote: > On Thu, Nov 17, 2022, Maxim Levitsky wrote: > > From: Santosh Shukla <santosh.shukla@amd.com> > > > > VMCB intr_ctrl bit12 (V_NMI_MASK) is set by the processor when handling > > NMI in guest and is cleared after the NMI is handled. Treat V_NMI_MASK > > as read-only in the hypervisor except for the SMM case where hypervisor > > before entring and after leaving SMM mode requires to set and unset > > V_NMI_MASK. > > > > Adding API(get_vnmi_vmcb) in order to return the correct vmcb for L1 or > > L2. > > > > Maxim: > > - made set_vnmi_mask/clear_vnmi_mask/is_vnmi_mask warn if called > > without vNMI enabled > > - clear IRET intercept in svm_set_nmi_mask even with vNMI > > > > Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > --- > > arch/x86/kvm/svm/svm.c | 18 ++++++++++++++- > > arch/x86/kvm/svm/svm.h | 52 ++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 69 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > index 08a7b2a0a29f3a..c16f68f6c4f7d7 100644 > > --- a/arch/x86/kvm/svm/svm.c > > +++ b/arch/x86/kvm/svm/svm.c > > @@ -3618,13 +3618,29 @@ static int svm_nmi_allowed(struct kvm_vcpu *vcpu, bool for_injection) > > > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > > { > > - return !!(vcpu->arch.hflags & HF_NMI_MASK); > > + struct vcpu_svm *svm = to_svm(vcpu); > > + > > + if (is_vnmi_enabled(svm)) > > + return is_vnmi_mask_set(svm); > > + else > > + return !!(vcpu->arch.hflags & HF_NMI_MASK); > > } > > > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > > { > > struct vcpu_svm *svm = to_svm(vcpu); > > > > + if (is_vnmi_enabled(svm)) { > > + if (masked) > > + set_vnmi_mask(svm); > > I believe not setting INTERCEPT_IRET is correct, but only because the existing > code is unnecessary. And this all very subtly relies on KVM_REQ_EVENT being set > and/or KVM already being in kvm_check_and_inject_events(). Actually after thinking about this again, I am almost sure that you are wrong about this: KVM sets INTERCEPT_IRET not only because of detection of NMI window but to know when the NMI handler execution ended. Even if no additional NMI arrives, if you don't intercept IRET, KVM will think that NMI are never unmasked, and in particular when another NMI arrives, KVM will try to open an NMI window while it is already open. Now the svm_set_nmi_mask masks NMI either when it is called by SMM entry point, or on migaration. On SMM entry point, most of the time the NMIs will be unmasked by RSM, but unsoliced IRET is also an (official) way to unmask NMI, which we will miss if we don't intercept IRET. On migartion, also, if it happened during NMI, we also have to intercept IRET once loading the migration stream so that we can know when NMI ended in the same way. All of this is of course only true for !vNMI case. For vNMI case it turns out that we don't need to intercept IRET at all after all: Turns out that when vNMI is pending, you can still EVENTINJ another NMI, and the pending vNMI will be kept pending, vNMI will became masked due to EVENTINJ, and on IRET the pending vNMI will be serviced as well, so in total both NMIs will be serviced. I confirmed this with Santosh Shukla, and in my patch series I take an advantage of this by failing the delayed NMI injection, and making KVM fail back to EVENTINJ. If NMIs are blocked (VNMI_MASKED bit set) on the other hand, and a vNMI is pending, then we can't use EVENTINJ to inject the second NMI, but in this case KVM drops the second NMI anyway. It all seems to add up very nicely, please take a look at the patch series ([PATCH v2 00/11] SVM: vNMI (with my fixes)) Best regards, Maxim Levitsky > > When NMIs become unblocked, INTERCEPT_IRET can be cleared, but KVM should also > pending KVM_REQ_EVENT. AFAICT, that doesn't happen when this is called via the > emulator. Ah, because em_iret() only handles RM for Intel's restricted guest > crap. I.e. it "works" only because it never happens. All other flows set > KVM_REQ_EVENT when toggling NMI blocking, e.g. the RSM path of kvm_smm_changed(). > > And when NMIs become blocked, there's no need to force INTERCEPT_IRET in this > code because kvm_check_and_inject_events() will request an NMI window and set the > intercept if necessary, and all paths that set NMI blocking are guaranteed to > reach kvm_check_and_inject_events() before entering the guest. > > 1. RSM => kvm_smm_changed() sets KVM_REQ_EVENT > 2. enter_smm() is only called from within kvm_check_and_inject_events(), > before pending NMIs are processed (yay priority) > 3. emulator_set_nmi_mask() never blocks NMIs, only does the half-baked IRET emulation > 4. kvm_vcpu_ioctl_x86_set_vcpu_event() sets KVM_REQ_EVENT > > So, can you add a prep patch to drop the forced INTERCEPT_IRET? That way the > logic for vNMI and !vNMI is the same. > > > + else { > > + clear_vnmi_mask(svm); > > This is the only code that sets/clears the vNMI mask, so rather than have set/clear > helpers, what about a single helper to do the dirty work? > > > + if (!sev_es_guest(vcpu->kvm)) > > + svm_clr_intercept(svm, INTERCEPT_IRET); > > + } > > + return; > > + } > > + > > if (masked) { > > vcpu->arch.hflags |= HF_NMI_MASK; > > if (!sev_es_guest(vcpu->kvm)) > > diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h > > index f5383104d00580..bf7f4851dee204 100644 > > --- a/arch/x86/kvm/svm/svm.h > > +++ b/arch/x86/kvm/svm/svm.h > > @@ -35,6 +35,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly; > > extern bool npt_enabled; > > extern int vgif; > > extern bool intercept_smi; > > +extern bool vnmi; > > > > enum avic_modes { > > AVIC_MODE_NONE = 0, > > @@ -531,6 +532,57 @@ static inline bool is_x2apic_msrpm_offset(u32 offset) > > (msr < (APIC_BASE_MSR + 0x100)); > > } > > > > +static inline struct vmcb *get_vnmi_vmcb(struct vcpu_svm *svm) > > +{ > > + if (!vnmi) > > + return NULL; > > + > > + if (is_guest_mode(&svm->vcpu)) > > + return svm->nested.vmcb02.ptr; > > + else > > + return svm->vmcb01.ptr; > > +} > > + > > +static inline bool is_vnmi_enabled(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (vmcb) > > + return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > > + else > > + return false; > > Maybe just this? > > return vmcb && (vmcb->control.int_ctl & V_NMI_ENABLE); > > Or if an inner helper is added: > > return vmcb && __is_vnmi_enabled(vmcb); > > > +} > > + > > +static inline bool is_vnmi_mask_set(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > Rather than WARN, add an inner __is_vnmi_enabled() that takes the vnmi_vmcb. > Actually, if you do that, the test/set/clear helpers can go away entirely. > > > + return false; > > + > > + return !!(vmcb->control.int_ctl & V_NMI_MASK); > > +} > > + > > +static inline void set_vnmi_mask(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > + return; > > + > > + vmcb->control.int_ctl |= V_NMI_MASK; > > +} > > + > > +static inline void clear_vnmi_mask(struct vcpu_svm *svm) > > +{ > > + struct vmcb *vmcb = get_vnmi_vmcb(svm); > > + > > + if (!WARN_ON_ONCE(!vmcb)) > > + return; > > + > > + vmcb->control.int_ctl &= ~V_NMI_MASK; > > +} > > These helpers can all go in svm. There are no users oustide of svm.c, and > unless I'm misunderstanding how nested works, there should never be oustide users. > > E.g. with HF_NMI_MASK => svm->nmi_masked, the end result can be something like: > > static bool __is_vnmi_enabled(struct *vmcb) > { > return !!(vmcb->control.int_ctl & V_NMI_ENABLE); > } > > static bool is_vnmi_enabled(struct vcpu_svm *svm) > { > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > return vmcb && __is_vnmi_enabled(vmcb); > } > > static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > if (vmcb && __is_vnmi_enabled(vmcb)) > return !!(vmcb->control.int_ctl & V_NMI_MASK); > else > return !!(vcpu->arch.hflags & HF_NMI_MASK); > } > > static void svm_set_or_clear_vnmi_mask(struct vmcb *vmcb, bool set) > { > if (set) > vmcb->control.int_ctl |= V_NMI_MASK; > else > vmcb->control.int_ctl &= ~V_NMI_MASK; > } > > static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) > { > struct vcpu_svm *svm = to_svm(vcpu); > struct vmcb *vmcb = get_vnmi_vmcb(svm); > > if (vmcb && __is_vnmi_enabled(vmcb)) { > if (masked) > vmcb->control.int_ctl |= V_NMI_MASK; > else > vmcb->control.int_ctl &= ~V_NMI_MASK; > } else { > svm->nmi_masked = masked; > } > > if (!masked) > svm_disable_iret_interception(svm); > } >
On Sun, Dec 04, 2022, Maxim Levitsky wrote: > For vNMI case it turns out that we don't need to intercept IRET at all after all: > > Turns out that when vNMI is pending, you can still EVENTINJ another NMI, and > the pending vNMI will be kept pending, vNMI will became masked due to > EVENTINJ, and on IRET the pending vNMI will be serviced as well, so in total > both NMIs will be serviced. I believe past me was thinking that the "merging" of pending NMIs happened in the context of the sender, but it always happens in the context of the target vCPU. Senders always do KVM_REQ_NMI, i.e. always kick if the vCPU in running, which gives KVM the hook it needs to update the VMCB. So yeah, as long as KVM can stuff two NMIs into the VMCB, I think we're good. I'll give the series a proper review in the next week or so.
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 08a7b2a0a29f3a..c16f68f6c4f7d7 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3618,13 +3618,29 @@ static int svm_nmi_allowed(struct kvm_vcpu *vcpu, bool for_injection) static bool svm_get_nmi_mask(struct kvm_vcpu *vcpu) { - return !!(vcpu->arch.hflags & HF_NMI_MASK); + struct vcpu_svm *svm = to_svm(vcpu); + + if (is_vnmi_enabled(svm)) + return is_vnmi_mask_set(svm); + else + return !!(vcpu->arch.hflags & HF_NMI_MASK); } static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked) { struct vcpu_svm *svm = to_svm(vcpu); + if (is_vnmi_enabled(svm)) { + if (masked) + set_vnmi_mask(svm); + else { + clear_vnmi_mask(svm); + if (!sev_es_guest(vcpu->kvm)) + svm_clr_intercept(svm, INTERCEPT_IRET); + } + return; + } + if (masked) { vcpu->arch.hflags |= HF_NMI_MASK; if (!sev_es_guest(vcpu->kvm)) diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index f5383104d00580..bf7f4851dee204 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -35,6 +35,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly; extern bool npt_enabled; extern int vgif; extern bool intercept_smi; +extern bool vnmi; enum avic_modes { AVIC_MODE_NONE = 0, @@ -531,6 +532,57 @@ static inline bool is_x2apic_msrpm_offset(u32 offset) (msr < (APIC_BASE_MSR + 0x100)); } +static inline struct vmcb *get_vnmi_vmcb(struct vcpu_svm *svm) +{ + if (!vnmi) + return NULL; + + if (is_guest_mode(&svm->vcpu)) + return svm->nested.vmcb02.ptr; + else + return svm->vmcb01.ptr; +} + +static inline bool is_vnmi_enabled(struct vcpu_svm *svm) +{ + struct vmcb *vmcb = get_vnmi_vmcb(svm); + + if (vmcb) + return !!(vmcb->control.int_ctl & V_NMI_ENABLE); + else + return false; +} + +static inline bool is_vnmi_mask_set(struct vcpu_svm *svm) +{ + struct vmcb *vmcb = get_vnmi_vmcb(svm); + + if (!WARN_ON_ONCE(!vmcb)) + return false; + + return !!(vmcb->control.int_ctl & V_NMI_MASK); +} + +static inline void set_vnmi_mask(struct vcpu_svm *svm) +{ + struct vmcb *vmcb = get_vnmi_vmcb(svm); + + if (!WARN_ON_ONCE(!vmcb)) + return; + + vmcb->control.int_ctl |= V_NMI_MASK; +} + +static inline void clear_vnmi_mask(struct vcpu_svm *svm) +{ + struct vmcb *vmcb = get_vnmi_vmcb(svm); + + if (!WARN_ON_ONCE(!vmcb)) + return; + + vmcb->control.int_ctl &= ~V_NMI_MASK; +} + /* svm.c */ #define MSR_INVALID 0xffffffffU