From: Borislav Petkov <bp@alien8.de>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Rik van Riel <riel@surriel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Fenghua Yu <fenghua.yu@intel.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates
Date: Thu, 20 Feb 2020 12:47:13 +0100 [thread overview]
Message-ID: <20200220114713.GB30188@zn.tnic> (raw)
In-Reply-To: <20200121201843.12047-2-yu-cheng.yu@intel.com>
On Tue, Jan 21, 2020 at 12:18:36PM -0800, Yu-cheng Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
>
> XCNTXT_MASK is 'all supported xfeatures' before introducing supervisor
> xstates. Rename it to SUPPORTED_XFEATURES_MASK_USER to make clear that
> these are user xstates.
>
> XFEATURE_MASK_SUPERVISOR is replaced with the following:
> - SUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently nothing. ENQCMD and
> Control-flow Enforcement Technology (CET) will be introduced in separate
> series.
> - UNSUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently only Processor Trace.
> - ALL_XFEATURES_MASK_SUPERVISOR: the combination of above.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> ---
> arch/x86/include/asm/fpu/xstate.h | 36 ++++++++++++++++++++-----------
> arch/x86/kernel/fpu/init.c | 3 ++-
> arch/x86/kernel/fpu/xstate.c | 26 +++++++++++-----------
> 3 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/arch/x86/include/asm/fpu/xstate.h b/arch/x86/include/asm/fpu/xstate.h
> index c6136d79f8c0..014c386deaa3 100644
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@ -21,19 +21,29 @@
> #define XSAVE_YMM_SIZE 256
> #define XSAVE_YMM_OFFSET (XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET)
>
> -/* Supervisor features */
> -#define XFEATURE_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> -
> -/* All currently supported features */
> -#define XCNTXT_MASK (XFEATURE_MASK_FP | \
> - XFEATURE_MASK_SSE | \
> - XFEATURE_MASK_YMM | \
> - XFEATURE_MASK_OPMASK | \
> - XFEATURE_MASK_ZMM_Hi256 | \
> - XFEATURE_MASK_Hi16_ZMM | \
> - XFEATURE_MASK_PKRU | \
> - XFEATURE_MASK_BNDREGS | \
> - XFEATURE_MASK_BNDCSR)
> +/* All currently supported user features */
> +#define SUPPORTED_XFEATURES_MASK_USER (XFEATURE_MASK_FP | \
> + XFEATURE_MASK_SSE | \
> + XFEATURE_MASK_YMM | \
> + XFEATURE_MASK_OPMASK | \
> + XFEATURE_MASK_ZMM_Hi256 | \
> + XFEATURE_MASK_Hi16_ZMM | \
> + XFEATURE_MASK_PKRU | \
> + XFEATURE_MASK_BNDREGS | \
> + XFEATURE_MASK_BNDCSR)
> +
> +/* All currently supported supervisor features */
> +#define SUPPORTED_XFEATURES_MASK_SUPERVISOR (0)
> +
> +/*
> + * Unsupported supervisor features. When a supervisor feature in this mask is
> + * supported in the future, move it to the supported supervisor feature mask.
> + */
> +#define UNSUPPORTED_XFEATURES_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> +
> +/* All supervisor states including supported and unsupported states. */
> +#define ALL_XFEATURES_MASK_SUPERVISOR (SUPPORTED_XFEATURES_MASK_SUPERVISOR | \
> + UNSUPPORTED_XFEATURES_MASK_SUPERVISOR)
So frankly having the namespace prepended in those macros makes it more
readable to me: you know that those masks all belong together if you had
this:
XFEATURE_MASK_SUPERVISOR
XFEATURE_MASK_SUPERVISOR_SUPPORTED
XFEATURE_MASK_SUPERVISOR_UNSUPPORTED
XFEATURE_MASK_SUPERVISOR_ALL
XFEATURE_MASK_USER_SUPPORTED
Now they all begin with different words: "ALL", "UNSUPPORTED",
"SUPPORTED", ... and makes you go and look up the mask to make sure it
is the correct type of mask used.
Even more so if the single feature masks also start with
"XFEATURE_MASK_" so it is only logical to have them all start with
XFEATURE_MASK_ IMO.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-02-20 11:47 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 20:18 [PATCH v2 0/8] Support XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates Yu-cheng Yu
2020-02-20 11:47 ` Borislav Petkov [this message]
2020-02-20 20:23 ` Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 2/8] x86/fpu/xstate: Separate user and supervisor xfeatures mask Yu-cheng Yu
2020-02-21 10:34 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 3/8] x86/fpu/xstate: Introduce XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 4/8] x86/fpu/xstate: Define new functions for clearing fpregs and xstates Yu-cheng Yu
2020-02-21 14:04 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 5/8] x86/fpu/xstate: Rename validate_xstate_header() to validate_xstate_header_from_user() Yu-cheng Yu
2020-02-21 14:13 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 6/8] x86/fpu/xstate: Update sanitize_restored_xstate() for supervisor xstates Yu-cheng Yu
2020-02-21 14:30 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 7/8] x86/fpu/xstate: Update copy_kernel_to_xregs_err() for XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 8/8] x86/fpu/xstate: Restore supervisor xstates for __fpu__restore_sig() Yu-cheng Yu
2020-02-21 17:58 ` Borislav Petkov
2020-02-27 22:52 ` Yu-cheng Yu
2020-02-28 12:17 ` Borislav Petkov
2020-02-28 12:51 ` Sebastian Andrzej Siewior
2020-02-28 15:53 ` Yu-cheng Yu
2020-02-28 16:23 ` Borislav Petkov
2020-02-28 16:20 ` Yu-cheng Yu
2020-02-28 16:50 ` Sebastian Andrzej Siewior
2020-02-28 16:54 ` Yu-cheng Yu
2020-02-28 17:22 ` Borislav Petkov
2020-02-28 18:11 ` Yu-cheng Yu
2020-02-28 18:31 ` Borislav Petkov
2020-02-28 21:22 ` Yu-cheng Yu
2020-02-28 21:47 ` Borislav Petkov
2020-02-28 22:13 ` Yu-cheng Yu
2020-02-29 14:36 ` Borislav Petkov
2020-03-02 18:09 ` Yu-cheng Yu
2020-03-04 18:18 ` Yu-cheng Yu
2020-03-06 20:50 ` Borislav Petkov
2020-03-10 20:36 ` Yu-cheng Yu
2020-03-10 21:16 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200220114713.GB30188@zn.tnic \
--to=bp@alien8.de \
--cc=bigeasy@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox