Message ID | 20221129193717.513824-10-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 q4csp537460wrr; Tue, 29 Nov 2022 11:54:01 -0800 (PST) X-Google-Smtp-Source: AA0mqf6u0x6YYwOQUYADjQHUuVoB+YBbt1KYRcYeiXZLzzmPvaYqd9TnTnpGJbQ738VD68aAs5zV X-Received: by 2002:a63:d356:0:b0:477:1a2:390e with SMTP id u22-20020a63d356000000b0047701a2390emr51814231pgi.83.1669751641259; Tue, 29 Nov 2022 11:54:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669751641; cv=none; d=google.com; s=arc-20160816; b=hVKELovYpsfP9i5InSfnj0yLc+Lt6Av4tiNIWndoENNRK8ptRt09INxc5cqL2BtcN2 nO66Wt3LQUfK7tILFPmDW4DMaHGdd93ERHhXRVxhgamZ4mVRzpTCdAzMH17dEdLU/Kfu tO2eQOlFwusGnpVlOiadDbqcxL92bU4ZRPJWFbQh/El/zimrWMfpHBpmx3mleXYUGTqA He7ygYFPh2Zxyx9FNACiew6ylBRIjP+mbQi0Y0/ySGemsQiyMQ3cBQ8omWFyHr7/6mmd K+33YZqXOF9xJ07H9PEkOmHbQ9Nc4hCL0vMB0bxPxMKNpNVmgU/SmeOL0uFplv+loyoG 8sPA== 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=8DWsatb5cdHreCXzHDkIF/f3CHfD6y+ENtUisNkNx+I=; b=A/cTln+uvtx0SWhHY+tYAcfY++BDAONMQBRYeeUvLSTlSMe/7K0OocN6BWRVXBPLdg tlWt2Zw6o6rRNbUMWNeUOZSJL/bv7RhPQ8qJhSbhFsI5VEysQzyCer6byMDfSZ9EmHj4 rZx+rTNycTZB463ujImpervPMoans5ExO/m+b/0BwkHW/6c6OSEpGOC/oedP9ohoBGIG wGOROeANYSYJUtHR1F9eAF9eJzl3Y84oP0VWD6GWUpCXS+t4lRxsZq+qFXsHb+QlTOFD TcXM8SROug0r3UbwjcqvKH5J2ieTWMA8ILz15fWfx2EsAuxg17ijnTHcaoTN/Nvycgd9 YsDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ep4aeZYx; 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 f17-20020a63f111000000b00477e302ee63si12971872pgi.552.2022.11.29.11.53.48; Tue, 29 Nov 2022 11:54:01 -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=Ep4aeZYx; 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 S236388AbiK2Tly (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 14:41:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236379AbiK2TlC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 14:41:02 -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 7ABCF48413 for <linux-kernel@vger.kernel.org>; Tue, 29 Nov 2022 11:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669750688; 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=8DWsatb5cdHreCXzHDkIF/f3CHfD6y+ENtUisNkNx+I=; b=Ep4aeZYxqLQbSqndVqAWdk/FErvY+K+6ihktH0wp6zp8oaf4RBs4n8BhzlfCCY0uyOZ/S2 bpCizXtpq0irtzVz/l8bvjHb7Hq9/V+QYNMP/4aoA3sxoK76RtB3YL5LJcuwb7mKhyDle5 kO7rNLC4m+SCecQVx0DMV6927sWQCUE= 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-76-r4lRUZj7OwCnv_6ASj17GA-1; Tue, 29 Nov 2022 14:38:01 -0500 X-MC-Unique: r4lRUZj7OwCnv_6ASj17GA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9F84C1C06ED8; Tue, 29 Nov 2022 19:38:00 +0000 (UTC) Received: from localhost.localdomain (unknown [10.35.206.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D7AE2028CE4; Tue, 29 Nov 2022 19:37:56 +0000 (UTC) From: Maxim Levitsky <mlevitsk@redhat.com> To: kvm@vger.kernel.org Cc: Sandipan Das <sandipan.das@amd.com>, Paolo Bonzini <pbonzini@redhat.com>, Jim Mattson <jmattson@google.com>, Peter Zijlstra <peterz@infradead.org>, Dave Hansen <dave.hansen@linux.intel.com>, Borislav Petkov <bp@alien8.de>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Daniel Sneddon <daniel.sneddon@linux.intel.com>, Jiaxi Chen <jiaxi.chen@linux.intel.com>, Babu Moger <babu.moger@amd.com>, linux-kernel@vger.kernel.org, Jing Liu <jing2.liu@intel.com>, Wyes Karny <wyes.karny@amd.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Sean Christopherson <seanjc@google.com>, Maxim Levitsky <mlevitsk@redhat.com>, Santosh Shukla <santosh.shukla@amd.com> Subject: [PATCH v2 09/11] KVM: SVM: Add VNMI bit definition Date: Tue, 29 Nov 2022 21:37:15 +0200 Message-Id: <20221129193717.513824-10-mlevitsk@redhat.com> In-Reply-To: <20221129193717.513824-1-mlevitsk@redhat.com> References: <20221129193717.513824-1-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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=ham 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?1750861497091650831?= X-GMAIL-MSGID: =?utf-8?q?1750861497091650831?= |
Series |
SVM: vNMI (with my fixes)
|
|
Commit Message
Maxim Levitsky
Nov. 29, 2022, 7:37 p.m. UTC
From: Santosh Shukla <santosh.shukla@amd.com> VNMI exposes 3 capability bits (V_NMI, V_NMI_MASK, and V_NMI_ENABLE) to virtualize NMI and NMI_MASK, Those capability bits are part of VMCB::intr_ctrl - V_NMI(11) - Indicates whether a virtual NMI is pending in the guest. V_NMI_MASK(12) - Indicates whether virtual NMI is masked in the guest. V_NMI_ENABLE(26) - Enables the NMI virtualization feature for the guest. When Hypervisor wants to inject NMI, it will set V_NMI bit, Processor will clear the V_NMI bit and Set the V_NMI_MASK which means the Guest is handling NMI, After the guest handled the NMI, The processor will clear the V_NMI_MASK on the successful completion of IRET instruction Or if VMEXIT occurs while delivering the virtual NMI. To enable the VNMI capability, Hypervisor need to program V_NMI_ENABLE bit 1. Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> --- arch/x86/include/asm/svm.h | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
On Tue, Nov 29, 2022, Maxim Levitsky wrote: > From: Santosh Shukla <santosh.shukla@amd.com> > > VNMI exposes 3 capability bits (V_NMI, V_NMI_MASK, and V_NMI_ENABLE) to > virtualize NMI and NMI_MASK, Those capability bits are part of > VMCB::intr_ctrl - > V_NMI(11) - Indicates whether a virtual NMI is pending in the guest. > V_NMI_MASK(12) - Indicates whether virtual NMI is masked in the guest. > V_NMI_ENABLE(26) - Enables the NMI virtualization feature for the guest. > > When Hypervisor wants to inject NMI, it will set V_NMI bit, Processor > will clear the V_NMI bit and Set the V_NMI_MASK which means the Guest is > handling NMI, After the guest handled the NMI, The processor will clear > the V_NMI_MASK on the successful completion of IRET instruction Or if > VMEXIT occurs while delivering the virtual NMI. > > To enable the VNMI capability, Hypervisor need to program > V_NMI_ENABLE bit 1. > > Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> > Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> > --- > arch/x86/include/asm/svm.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h > index cb1ee53ad3b189..26d6f549ce2b46 100644 > --- a/arch/x86/include/asm/svm.h > +++ b/arch/x86/include/asm/svm.h > @@ -203,6 +203,13 @@ struct __attribute__ ((__packed__)) vmcb_control_area { > #define X2APIC_MODE_SHIFT 30 > #define X2APIC_MODE_MASK (1 << X2APIC_MODE_SHIFT) > > +#define V_NMI_PENDING_SHIFT 11 > +#define V_NMI_PENDING (1 << V_NMI_PENDING_SHIFT) > +#define V_NMI_MASK_SHIFT 12 > +#define V_NMI_MASK (1 << V_NMI_MASK_SHIFT) Argh, more KVM warts. The existing INT_CTL defines all use "mask" in the name, so looking at V_NMI_MASK in the context of other code reads "vNMI is pending", not "vNMIs are blocked". IMO, the existing _MASK terminology is the one that's wrong, but there's an absurd amount of prior art in svm.h :-( And the really annoying one is V_INTR_MASKING_MASK, which IIRC says "virtual INTR masking is enabled", not "virtual INTRs are blocked". So maybe call this V_NMI_BLOCKING_MASK? And tack on _MASK too the others (even though I agree it's ugly). > +#define V_NMI_ENABLE_SHIFT 26 > +#define V_NMI_ENABLE (1 << V_NMI_ENABLE_SHIFT) Hrm. I think I would prefer to keep the defines ordered by bit position. Knowing that there's an enable bit isn't all that critical for understanding vNMI pending and blocked.
On 2/1/2023 4:12 AM, Sean Christopherson wrote: > On Tue, Nov 29, 2022, Maxim Levitsky wrote: >> From: Santosh Shukla <santosh.shukla@amd.com> >> >> VNMI exposes 3 capability bits (V_NMI, V_NMI_MASK, and V_NMI_ENABLE) to >> virtualize NMI and NMI_MASK, Those capability bits are part of >> VMCB::intr_ctrl - >> V_NMI(11) - Indicates whether a virtual NMI is pending in the guest. >> V_NMI_MASK(12) - Indicates whether virtual NMI is masked in the guest. >> V_NMI_ENABLE(26) - Enables the NMI virtualization feature for the guest. >> >> When Hypervisor wants to inject NMI, it will set V_NMI bit, Processor >> will clear the V_NMI bit and Set the V_NMI_MASK which means the Guest is >> handling NMI, After the guest handled the NMI, The processor will clear >> the V_NMI_MASK on the successful completion of IRET instruction Or if >> VMEXIT occurs while delivering the virtual NMI. >> >> To enable the VNMI capability, Hypervisor need to program >> V_NMI_ENABLE bit 1. >> >> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> >> Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> >> --- >> arch/x86/include/asm/svm.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h >> index cb1ee53ad3b189..26d6f549ce2b46 100644 >> --- a/arch/x86/include/asm/svm.h >> +++ b/arch/x86/include/asm/svm.h >> @@ -203,6 +203,13 @@ struct __attribute__ ((__packed__)) vmcb_control_area { >> #define X2APIC_MODE_SHIFT 30 >> #define X2APIC_MODE_MASK (1 << X2APIC_MODE_SHIFT) >> >> +#define V_NMI_PENDING_SHIFT 11 >> +#define V_NMI_PENDING (1 << V_NMI_PENDING_SHIFT) >> +#define V_NMI_MASK_SHIFT 12 >> +#define V_NMI_MASK (1 << V_NMI_MASK_SHIFT) > > Argh, more KVM warts. The existing INT_CTL defines all use "mask" in the name, > so looking at V_NMI_MASK in the context of other code reads "vNMI is pending", > not "vNMIs are blocked". > > IMO, the existing _MASK terminology is the one that's wrong, but there's an absurd > amount of prior art in svm.h :-( > > And the really annoying one is V_INTR_MASKING_MASK, which IIRC says "virtual INTR > masking is enabled", not "virtual INTRs are blocked". > > So maybe call this V_NMI_BLOCKING_MASK? And tack on _MASK too the others (even > though I agree it's ugly). > Sure. >> +#define V_NMI_ENABLE_SHIFT 26 >> +#define V_NMI_ENABLE (1 << V_NMI_ENABLE_SHIFT) > > Hrm. I think I would prefer to keep the defines ordered by bit position. Knowing > that there's an enable bit isn't all that critical for understanding vNMI pending > and blocked. Sure, Sean will include in V3. Thanks, Santosh
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h index cb1ee53ad3b189..26d6f549ce2b46 100644 --- a/arch/x86/include/asm/svm.h +++ b/arch/x86/include/asm/svm.h @@ -203,6 +203,13 @@ struct __attribute__ ((__packed__)) vmcb_control_area { #define X2APIC_MODE_SHIFT 30 #define X2APIC_MODE_MASK (1 << X2APIC_MODE_SHIFT) +#define V_NMI_PENDING_SHIFT 11 +#define V_NMI_PENDING (1 << V_NMI_PENDING_SHIFT) +#define V_NMI_MASK_SHIFT 12 +#define V_NMI_MASK (1 << V_NMI_MASK_SHIFT) +#define V_NMI_ENABLE_SHIFT 26 +#define V_NMI_ENABLE (1 << V_NMI_ENABLE_SHIFT) + #define LBR_CTL_ENABLE_MASK BIT_ULL(0) #define VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK BIT_ULL(1)