Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp60597rwb; Wed, 10 Aug 2022 14:52:04 -0700 (PDT) X-Google-Smtp-Source: AA6agR7SoAkaRsiDB8Qs0gyv9OU2xWTSTrsT4p+mBCFwk9n0voMEdD6NV++NGSSo8MQnXvpC37RC X-Received: by 2002:a63:e348:0:b0:41b:444f:ff5f with SMTP id o8-20020a63e348000000b0041b444fff5fmr23731897pgj.333.1660168324513; Wed, 10 Aug 2022 14:52:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660168324; cv=none; d=google.com; s=arc-20160816; b=AEP/A2g4So4hjaCT4BBmfFFT2xkNkbO/YVF7aufNdCbS9W4TJQXTql7W0kRxXelZ6e Jy+3GVV+suIruW3+64Ab1U70s4yKEO9992j1NZ3su50DZ4Auw3fuBPtB6d2k7A4OORKH Ix6cjQmqpiSYnT5H0M1Li/DIUjYI32SJo7dhiC3fB5AeMLZ9l7XHlVhFV1IwnNeZZCz5 4iKTSFvt2+RJAwDfw4cOufrsYyIIpqm3tSBKyaUvFeLL3RNFnfKDj2XPwvkDkd3fspl9 qOJtn5b3Aj/pqvd2bUNO7DBWnDA7apcKKa5yXfx0cdKEQL2n2y5z2k84Hr1EIiKhmv2E FRLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=aMwgJ2SQ/m0Yl6VmAGvUrjsVPWaHByE1eYAW0OiolJs=; b=dn4QbnpBR2UGE2IhN9RoxH+7+293nW38oG8WqFyL1AcDhqHjcDrH4VFC0OALpr9p0I FzujZrt6Iitk7lMLQ+cTpBI9rOgXvhhru+nn4qJSoMbOO9uS4Ow2j3nK9C2N5yabv1LW 6B8ibnWr+18ecnY6Ca6+lnVRbPUDZ13L+I5UfbmcYwNHYRTacLUZ+adT7AQLKkHTYsay llOrKzfqPVbaakhdiiq/Mwvo3MyvBjI2x/sVOTJK+ZuZDTE3bvoORUIwTw23Pf9qx2GG pRiOhOIv7eYpex+eg1KjcaIHYnnGjuq2Wvi2Xdw3lRUyUvOSaqDByon6WAv087IhQPrP A3cw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s2-20020a170902ea0200b0016dbee11800si20318452plg.326.2022.08.10.14.51.51; Wed, 10 Aug 2022 14:52:04 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232908AbiHJVYg (ORCPT + 99 others); Wed, 10 Aug 2022 17:24:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232960AbiHJVYc (ORCPT ); Wed, 10 Aug 2022 17:24:32 -0400 Received: from vps-vb.mhejs.net (vps-vb.mhejs.net [37.28.154.113]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B40D71712; Wed, 10 Aug 2022 14:24:28 -0700 (PDT) Received: from MUA by vps-vb.mhejs.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1oLtBb-0001Cc-92; Wed, 10 Aug 2022 23:24:19 +0200 Message-ID: Date: Wed, 10 Aug 2022 23:24:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Santosh Shukla Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, mlevitsk@redhat.com References: <20220810061226.1286-1-santosh.shukla@amd.com> <20220810061226.1286-6-santosh.shukla@amd.com> From: "Maciej S. Szmigiero" Subject: Re: [PATCHv3 5/8] KVM: SVM: Add VNMI support in inject_nmi In-Reply-To: <20220810061226.1286-6-santosh.shukla@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On 10.08.2022 08:12, Santosh Shukla wrote: > Inject the NMI by setting V_NMI in the VMCB interrupt control. processor > will clear V_NMI to acknowledge processing has started and will keep the > V_NMI_MASK set until the processor is done with processing the NMI event. > > Signed-off-by: Santosh Shukla > --- > v3: > - Removed WARN_ON check. > > v2: > - Added WARN_ON check for vnmi pending. > - use `get_vnmi_vmcb` to get correct vmcb so to inject vnmi. > > arch/x86/kvm/svm/svm.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index e260e8cb0c81..8c4098b8a63e 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -3479,7 +3479,14 @@ static void pre_svm_run(struct kvm_vcpu *vcpu) > static void svm_inject_nmi(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > + struct vmcb *vmcb = NULL; > > + if (is_vnmi_enabled(svm)) { I guess this should be "is_vnmi_enabled(svm) && !svm->nmi_l1_to_l2" since if nmi_l1_to_l2 is true then the NMI to be injected originally comes from L1's VMCB12 EVENTINJ field. As you said in the cover letter, this field has different semantics than vNMI - specifically, it should allow injecting even if L2 is in NMI blocking state (it's then up to L1 to keep track of NMI injectability for its L2 guest - so L0 should be transparently injecting it when L1 wants so). > + vmcb = get_vnmi_vmcb(svm); > + vmcb->control.int_ctl |= V_NMI_PENDING; > + ++vcpu->stat.nmi_injections; > + return; > + } > svm->vmcb->control.event_inj = SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_NMI; > > if (svm->nmi_l1_to_l2) Thanks, Maciej