linux-kernel - Re: [PATCHv4 1/8] x86/cpu: Add CPUID feature bit for VNMI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALMp9eT3zHqZhDLKV=5UTnwLsvmbkpqibsh4tjqFnW4+MGR4aw@mail.gmail.com>
Date:   Thu, 1 Sep 2022 10:43:07 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     "Shukla, Santosh" <santosh.shukla@....com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        Tom Lendacky <thomas.lendacky@....com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, mlevitsk@...hat.com,
        mail@...iej.szmigiero.name
Subject: Re: [PATCHv4 1/8] x86/cpu: Add CPUID feature bit for VNMI

On Thu, Sep 1, 2022 at 5:45 AM Shukla, Santosh <santosh.shukla@....com> wrote:
>
> Hi Jim,
>
> On 9/1/2022 5:12 AM, Jim Mattson wrote:
> > On Mon, Aug 29, 2022 at 3:09 AM Santosh Shukla <santosh.shukla@....com> wrote:
> >>
> >> VNMI feature allows the hypervisor to inject NMI into the guest w/o
> >> using Event injection mechanism, The benefit of using VNMI over the
> >> event Injection that does not require tracking the Guest's NMI state and
> >> intercepting the IRET for the NMI completion. VNMI achieves that by
> >> exposing 3 capability bits in VMCB intr_cntrl which helps with
> >> virtualizing NMI injection and NMI_Masking.
> >>
> >> The presence of this feature is indicated via the CPUID function
> >> 0x8000000A_EDX[25].
> >>
> >> Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>
> >> Signed-off-by: Santosh Shukla <santosh.shukla@....com>
> >> ---
> >>  arch/x86/include/asm/cpufeatures.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> >> index ef4775c6db01..33e3603be09e 100644
> >> --- a/arch/x86/include/asm/cpufeatures.h
> >> +++ b/arch/x86/include/asm/cpufeatures.h
> >> @@ -356,6 +356,7 @@
> >>  #define X86_FEATURE_VGIF               (15*32+16) /* Virtual GIF */
> >>  #define X86_FEATURE_X2AVIC             (15*32+18) /* Virtual x2apic */
> >>  #define X86_FEATURE_V_SPEC_CTRL                (15*32+20) /* Virtual SPEC_CTRL */
> >> +#define X86_FEATURE_V_NMI              (15*32+25) /* Virtual NMI */
> >>  #define X86_FEATURE_SVME_ADDR_CHK      (15*32+28) /* "" SVME addr check */
> >
> > Why is it "V_NMI," but "VGIF"?
> >
> I guess you are asking why I chose V_NMI and not VNMI, right?
> if so then there are two reasons for going with V_NMI - IP bits are named in order
> V_NMI, V_NMI_MASK, and V_NMI_ENABLE style and also Intel already using VNMI (X86_FEATURE_VNMI)

I would argue that inconsistency and arbitrary underscores
unnecessarily increase the cognitive load. It is not immediately
obvious to me that an extra underscore implies AMD. What's wrong with
X86_FEATURE_AMD_VNMI? We already have over half a dozen AMD feature
bits that are distinguished from the Intel version by an AMD prefix.