linux-kernel - Re: [PATCH v3 2/2] x86/xstate: Make AVX512 status tracking more accurate

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]

Date:   Wed, 27 Oct 2021 19:11:27 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Noah Goldstein <goldstein.w.n@...il.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
        hpa@...or.com, luto@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] x86/xstate: Make AVX512 status tracking more
 accurate

On Wed, Oct 27, 2021 at 11:26:15AM -0500, Noah Goldstein wrote:
> diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
> index f5a38a5f3ae1..cb10909fa3da 100644
> --- a/arch/x86/include/asm/fpu/types.h
> +++ b/arch/x86/include/asm/fpu/types.h
> @@ -330,11 +330,21 @@ struct fpu {
>  	unsigned int			last_cpu;
>  
>  	/*
> -	 * @avx512_timestamp:
> +	 * @avx512_ZMM_Hi256_timestamp:
>  	 *
> -	 * Records the timestamp of AVX512 use during last context switch.
> +	 * Records the timestamp of AVX512 use in the ZMM_Hi256 xfeature
> +	 * set. This include zmm0...zmm15.
>  	 */
> -	unsigned long			avx512_timestamp;
> +	unsigned long			avx512_ZMM_Hi256_timestamp;
> +
> +	/*
> +	 * @avx512_Hi16_ZMM_timestamp:
> +	 *
> +	 * Records the timestamp of AVX512 use in the Hi16_ZMM xfeature
> +	 * set. This includes usage of any of the hi16 xmm, ymm, or zmm
> +	 * registers.
> +	 */
> +	unsigned long			avx512_Hi16_ZMM_timestamp;

No, not more of this but less.

That was a bad idea to begin with as exposing this to userspace would
cause exactly this: but but, I need to track my special use case more
precisely.

But the feature mask can't give you that precision so it'll be only an
approximation no matter what you do.

And I'm being told future cores won't have this "problem" so on them
that file becomes actively misleading.

If you really wanna track performance drop precisely or AVX use or
whatnot, there's performance counters for that which can give you
exactly what you wanna know.

So I'll take a simple patch carving out that into a function and which
removes the opmask and otherwise let that thing die. And on future cores
which are not affected, that thing will report only 0 anyway.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette