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 10690C636D3 for ; Wed, 1 Feb 2023 00:39:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231786AbjBAAjO (ORCPT ); Tue, 31 Jan 2023 19:39:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229946AbjBAAjN (ORCPT ); Tue, 31 Jan 2023 19:39:13 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 497F8268B for ; Tue, 31 Jan 2023 16:39:12 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id r8so9995633pls.2 for ; Tue, 31 Jan 2023 16:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=F0GdAR0v2Ntap0HJ2NsIfGxXKqahI5FZuPXOS/K2KC8=; b=jfZouOb9QzsPA9F1x1KNbo/JJtUMImiTs/0XZ1IPXMdH380nQVF2mgqAIZvHfKYw69 eBzKoDBa3k7olWv/obXmKpC8jiInJkB6UEPnSVwYyt4P+/jjtaij9YsulaZSm8OaxJxn obOxPykXNicw+0EtKRbilD8jCywvc2GJCg+vP2eUbIDXSZyHhjrJGwH93lwM/gM19anY 35AKuGMKKVdVPLsM4VQETEIxclTiEdawM7a3QsZkfdmFjQyetK4X+fLNyza0RrJJj2Sy izFzg6rBa1WsXQ94YpQuATpO5nRXIoHcdZwfTZYF2h2KaHh42iIE4fWL2amQommsSSGy HzMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=F0GdAR0v2Ntap0HJ2NsIfGxXKqahI5FZuPXOS/K2KC8=; b=mCKuKDfmF5BuEGX78BnpVQ+KqY4qqxaILRy1vUY6YtfvwpdeZt/np9Y8A6WWL5rkul 18vF2/qIq1UfYIE5ar7cychf6ZZexq1bIVo4W7AzrG6VMRDAxGuJbd+ASNtJ7cUpLZCr QHrQvPpYRLU5HYzC9wkybjDWeVVbfOdmMFeBLpoo0jgMywtSvInap2jZEZD+LnObOHM0 Z5LchrqTGy7HKE1JJ2as3F+GsrAURbKBy1VSXQsOqL2xmV7gswI9PG2q6g5lICya2uLw u1837xhMaysu9Ob3tD+Wdi+ZbdmsRueZmJEnkF/43aiYFmgvUFMjH08J7EdsMwwouKx3 j+UA== X-Gm-Message-State: AO0yUKUTlt9cUXRWdJxemnts18G6t9F7dyHY62xhD6U7fumqmPRx4j1e nB5vNCPwfYdRayi4+1BpBqQNFw== X-Google-Smtp-Source: AK7set8ZASSGw1z1PfZ59ELQwPnBtuiLKg0zGfgCijzGy0WTF3y5sge/CYZ3szc/5gs8AK7VwYGNKw== X-Received: by 2002:a17:902:7882:b0:198:af50:e4e9 with SMTP id q2-20020a170902788200b00198af50e4e9mr2680pll.15.1675211951629; Tue, 31 Jan 2023 16:39:11 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id f190-20020a636ac7000000b004a737a6e62fsm8933232pgc.14.2023.01.31.16.39.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Jan 2023 16:39:11 -0800 (PST) Date: Wed, 1 Feb 2023 00:39:07 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: kvm@vger.kernel.org, Sandipan Das , Paolo Bonzini , Jim Mattson , Peter Zijlstra , Dave Hansen , Borislav Petkov , Pawan Gupta , Thomas Gleixner , Ingo Molnar , Josh Poimboeuf , Daniel Sneddon , Jiaxi Chen , Babu Moger , linux-kernel@vger.kernel.org, Jing Liu , Wyes Karny , x86@kernel.org, "H. Peter Anvin" , Santosh Shukla Subject: Re: [PATCH v2 10/11] KVM: SVM: implement support for vNMI Message-ID: References: <20221129193717.513824-1-mlevitsk@redhat.com> <20221129193717.513824-11-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 01, 2023, Sean Christopherson wrote: > On Tue, Nov 29, 2022, Maxim Levitsky wrote: > > @@ -553,6 +554,15 @@ static inline bool is_x2apic_msrpm_offset(u32 offset) > > (msr < (APIC_BASE_MSR + 0x100)); > > } > > > > +static inline bool is_vnmi_enabled(struct vcpu_svm *svm) > > +{ > > + /* L1's vNMI is inhibited while nested guest is running */ > > + if (is_guest_mode(&svm->vcpu)) > > I would rather check the current VMCB. I don't see any value in hardcoding the > "KVM doesn't support vNMI in L2" in multiple places. And I find the above comment > about "L1's vNMI is inhibited" confusing. vNMI isn't inhibited/blocked, KVM just > doesn't utilize vNMI while L2 is active (IIUC, as proposed). Oof. Scratch that, code is correct as proposed, but the comment and function name are confusing. After looking at the nested support, is_vnmi_enabled() actually means "is vNMI currently enabled _for L1_". And it has less to do with vNMI being "inhibited" and everything to do with KVM choosing not to utilize vNMI for L1 while running L2. "inhibited" in quotes because "inhibited" is a synonym of "blocked", i.e. I read that as L1 NMIs are blocked. So regardless of whether or not KVM decides to utilize vNMI for L2 if L1's NMIs are passed through, the function name needs to clarify that it's referring to L1. E.g. is_vnmi_enabled_for_l1() or so. And if KVM decides not to use vNMI for L1 while running L2, state that more explicitly instead of saying it's inhibited. And if KVM does decide to use vNMI while running L2 if NMIs are passed through, then the comment goes away and KVM toggles the flag in vmcb01 on nested enter and exit. > > + return false; > > + > > + return !!(svm->vmcb01.ptr->control.int_ctl & V_NMI_ENABLE); > > +} > > + > > /* svm.c */ > > #define MSR_INVALID 0xffffffffU > > > > -- > > 2.26.3 > >