Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ad56eb5a-a999-52b4-4c5d-4ff4b124b0a0@redhat.com>
Date:   Thu, 3 Nov 2022 14:26:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap
 instead of clear_cpu_cap
Content-Language: en-US
To:     "H. Peter Anvin" <hpa@zytor.com>,
        "Elliott, Robert (Servers)" <elliott@hpe.com>,
        Borislav Petkov <bp@alien8.de>,
        Maxim Levitsky <mlevitsk@redhat.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Josh Poimboeuf <jpoimboe@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Tony Luck <tony.luck@intel.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Chang S. Bae" <chang.seok.bae@intel.com>,
        Jane Malalane <jane.malalane@citrix.com>,
        Kees Cook <keescook@chromium.org>,
        Kan Liang <kan.liang@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Jiri Olsa <jolsa@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        "linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,
        "open list:CRYPTO API" <linux-crypto@vger.kernel.org>
References: <20220718141123.136106-1-mlevitsk@redhat.com>
 <20220718141123.136106-2-mlevitsk@redhat.com> <Yyh9RDbaRqUR1XSW@zn.tnic>
 <c105971a72dfe6d46ad75fb7e71f79ba716e081c.camel@redhat.com>
 <YzGlQBkCSJxY+8Jf@zn.tnic>
 <c1168e8bd9077a2cc9ef61ee06db7a4e8c0f1600.camel@redhat.com>
 <Y1EOBAaLbv2CXBDL@zn.tnic> <fd2cf028-bd83-57ff-7e6d-ef3ee11852a1@redhat.com>
 <MW5PR84MB18428331677C881764E615D2AB399@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
 <EFDA4E40-4133-4CED-97FA-DC75AEA24556@zytor.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <EFDA4E40-4133-4CED-97FA-DC75AEA24556@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/2/22 17:23, H. Peter Anvin wrote:
> We have a dependency system for CPUID features. If you are going to
> do this (as opposed to "fixing" this in Qemu or just saying "don't do
> that, it isn't a valid hardware configuration."

I didn't check Robert's full list, but at least in the case of 
aesni-intel_glue this is not about AVX2-depends-on-AVX or 
AVX-depends-on-XSAVE (and it is not about QEMU at all).  It's just that 
checking AVX or AVX2 only tells you about presence and is not enough to 
say whether the instructions are _usable_.  Likewise for AVX512.

What would the dependency be?

Paolo

> 
> 
> 1. Currently checking XSAVE YMM:
>  aria_aesni_avx_glue
>  blake2s-glue
>  camellia_aesni_avx2_glue	camellia_aesni_avx_glue
>  cast5_avx_glue		cast6_avx_glue
>  chacha_glue
>  poly1305_glue
>  serpent_avx2_glue		serpent_avx_glue
>  sha1_ssse3_glue		sha256_ssse3_glue	sha512_ssse3_glue
>  sm3_avx_glue
>  sm4_aesni_avx2_glue	sm4_aesni_avx_glue
>  twofish_avx_glue
> 
> Currently not checking XSAVE YMM:
>  aesni-intel_glue
>  curve25519-x86_64
>  nhpoly1305-avx2-glue
>  polyval-clmulni_glue
> 
> 2. Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL
> and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512:
> 
> Currently checking XSAVE AVX512:
>  blake2s-glue
>  poly1305_glue
> 
> Currently not checking XSAVE AVX512:
>  chacha_glue
> 
> 3. Similarly, modules using X86_FEATURE_XMM2 probably need to
> check XFEATURE_MASK_SSE:
> 
> Currently checking XSAVE SSE:
>  aegis128-aesni-glue 
> 
> Current not checking XSAVE SSE:
>  nhpoly1305-sse2_glue
>  serpent_sse2_glue
>