Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp5897186imw; Wed, 20 Jul 2022 15:08:00 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v3ZbKHeh5f2AL6WXWkvuBO6ZGPv9br9lVhbcydqnEQWByrq1VZ7uZpZDBkkdz0n/08IDC0 X-Received: by 2002:a05:6602:21d1:b0:67b:d23b:b68d with SMTP id c17-20020a05660221d100b0067bd23bb68dmr15195507ioc.104.1658354880681; Wed, 20 Jul 2022 15:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658354880; cv=none; d=google.com; s=arc-20160816; b=ocPUZRNjpxVyrroqcdgTUh0han9D7U7PyBE7P7HRdIsNNwSMKmvIjNn6unpsA3Vn12 hDkScX45ZX9zLE0eOpRPPAepqe1qeXmd0lYNzVow3UCmxmpUPyjg9cs9IKY5grn5v6UB aEa0IGveLV0sQAVF3ZytAAtdyuMu4MWXwMdlMjpV0yJL99dwRPfZ6aQ6PqnhFBTgJQi5 7xn7RjCyrucGLxEkxFnZifymk9GMIsfvcyFDCZxuJrsL97sNV2nPk6dLiYy220uMoUFv YxIUL10+i+LhM2gf/EMC8v7649dEfgBV73t13HHkBg9/oETjuUS4G5jrJ7MWIF3s9Eql LODg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jK6tZAVLlpKQaYUdrFhp6jMza1P7Y68lK+h4BL/v32U=; b=GnbIGb1Xo9/XrTIZxrGBMBJAsiR9YHJHoush17TMiBLYnFEscyNIW3jYGnCku791XR uPod434F9u5HoTVYq3tbs/3PKZ3F8GiyF1T0VCTve3Xrb1h3MbZVX/Yy+emRmK8lAarF E+afH/RIqQRRNl3HmhsVmNTkoSYLGEykO6dXj0acgVyeVkqhK/Aq9iWB1ps0868+5gQI QcpJJeO/uG01sp5JByf44pPbDMnF87kUqgvhBsGzKI1orlKhpDZE0FrhXuzBbD/WwI0C gA7ONhpgO8sNioyiZ6zXFMtW56bktVjXLR+1v6Xc4ro1cOxG02Lm6iHhgwNmFeodowiB WBlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bb98mV59; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m10-20020a92870a000000b002dc683efe5esi144309ild.151.2022.07.20.15.07.45; Wed, 20 Jul 2022 15:08:00 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=bb98mV59; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230198AbiGTVyV (ORCPT + 99 others); Wed, 20 Jul 2022 17:54:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbiGTVyU (ORCPT ); Wed, 20 Jul 2022 17:54:20 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A561248C8D for ; Wed, 20 Jul 2022 14:54:19 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id f3-20020a17090ac28300b001f22d62bfbcso166249pjt.0 for ; Wed, 20 Jul 2022 14:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jK6tZAVLlpKQaYUdrFhp6jMza1P7Y68lK+h4BL/v32U=; b=bb98mV59J227Gzh/7pVgul7s8I0m8osIYW3lUlal2sBMW6xjav+1p6xkJtJazn3Mok J//BBdPQpXecD7+EhWvOvCltmXpnI/a/ICbDRKTuq61zuiZvri80vPGiEUUmaJqFF3Mi Zi2WDSRXPk/Soa8PjpvEWT8m2FCXt05Ib1eBWCA8ivsbdCpnTy4ghKR1pDhsVln29nQk tcO+yHWxsR5A34ZKgL0lPbUsfqQU08E1MULduTTsedAm7FJMOeoGj53+SQafmoeDD3r9 rrcdvQzIls9I15ogFqdOjwcAwOHhfa9z1J/ncy147O1ttAStxNqJUzKgiwV3icnRz0mX A7WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jK6tZAVLlpKQaYUdrFhp6jMza1P7Y68lK+h4BL/v32U=; b=68xjtrzm5rZRp51jg5ed6mIM6cWZcq5DXY9Bdfs9T0BzHfs9ltR5L6J0vtG3JTRqwq v2jYrQi6WkOVGqlGbTbWFKlHN3keivAMG7RLkkCLE6D3CcThQ1LiJuU5MPdoLXvDs9C8 lbMc0XgdvZdZ0uCCZBC0MdTnhy6eqlEevAfEaUiHnFfcDyhuGjD/1hDXRNgFtvHt5qE5 lMUDtb4y+nuLNUTaLGI1j2kPJvYItTiC7fFpS7KLBdCXB9tEEb4/SL+TP5m3FeMHmZmh rr3/SPYVJwnM10pb46jQ0O7hAiGUf5c5Aok505qieODJMK56uvmzGTwcftNSNxwhH7bw 7iZg== X-Gm-Message-State: AJIora9PmgPQPCX2M+WJCS7FJvqAaQB9US5hg6yQBMetjqkLqfG54Z6t ZfzfR7KeR+nBh6eLz70HY97uog== X-Received: by 2002:a17:902:e886:b0:16b:faee:ccfc with SMTP id w6-20020a170902e88600b0016bfaeeccfcmr41017840plg.114.1658354059054; Wed, 20 Jul 2022 14:54:19 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id u22-20020a17090adb5600b001f1a8c24b5esm2167407pjx.6.2022.07.20.14.54.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 14:54:18 -0700 (PDT) Date: Wed, 20 Jul 2022 21:54:14 +0000 From: Sean Christopherson To: Santosh Shukla Cc: Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , Maxim Levitsky , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 4/7] KVM: SVM: Report NMI not allowed when Guest busy handling VNMI Message-ID: References: <20220709134230.2397-1-santosh.shukla@amd.com> <20220709134230.2397-5-santosh.shukla@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220709134230.2397-5-santosh.shukla@amd.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Sat, Jul 09, 2022, Santosh Shukla wrote: > In the VNMI case, Report NMI is not allowed when the processor set the > V_NMI_MASK to 1 which means the Guest is busy handling VNMI. > > Signed-off-by: Santosh Shukla > --- > v2: > - Moved vnmi check after is_guest_mode() in func _nmi_blocked(). > - Removed is_vnmi_mask_set check from _enable_nmi_window(). > as it was a redundent check. > > arch/x86/kvm/svm/svm.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 3574e804d757..44c1f2317b45 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -3480,6 +3480,9 @@ bool svm_nmi_blocked(struct kvm_vcpu *vcpu) > if (is_guest_mode(vcpu) && nested_exit_on_nmi(svm)) > return false; > > + if (is_vnmi_enabled(svm) && is_vnmi_mask_set(svm)) > + return true; > + > ret = (vmcb->control.int_state & SVM_INTERRUPT_SHADOW_MASK) || > (vcpu->arch.hflags & HF_NMI_MASK); > > @@ -3609,6 +3612,9 @@ static void svm_enable_nmi_window(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > > + if (is_vnmi_enabled(svm)) > + return; Ugh, is there really no way to trigger an exit when NMIs become unmasked? Because if there isn't, this is broken for KVM. On bare metal, if two NMIs arrive "simultaneously", so long as NMIs aren't blocked, the first NMI will be delivered and the second will be pended, i.e. software will see both NMIs. And if that doesn't hold true, the window for a true collision is really, really tiny. But in KVM, because a vCPU may not be run a long duration, that window becomes very large. To not drop NMIs and more faithfully emulate hardware, KVM allows two NMIs to be _pending_. And when that happens, KVM needs to trigger an exit when NMIs become unmasked _after_ the first NMI is injected. > + > if ((vcpu->arch.hflags & (HF_NMI_MASK | HF_IRET_MASK)) == HF_NMI_MASK) > return; /* IRET will cause a vm exit */ > > -- > 2.25.1 >