Re: [PATCH v11 15/29] x86/arch_prctl: Create ARCH_SET_STATE_ENABLE/ARCH_GET_STATE_ENABLE

From: Peter Zijlstra
Date: Tue Oct 05 2021 - 07:24:48 EST


On Tue, Oct 05, 2021 at 11:49:05AM +0200, Thomas Gleixner wrote:
> So this gives us two options:
>
> 1) Bitmap with proper sanity checks
>
> reject (1 << 17) and (1 << 18)
> grant (1 << 17 | 1 << 18)
>
> but for sanity sake and also for ease of filtering, we want to
> restrict a permission request to one functional block at a time.
>
> #define X86_XCOMP_AMX (1 << 17 | 1 << 18)
> #define X86_XCOMP_XYZ1 (1 << 19)
>
> But that gets a bit odd when there is a component which depends on
> others:
>
> #define X86_XCOMP_XYZ2 (1 << 19 | 1 << 20)
>
> 2) Facility based numerical interface, i.e.
>
> #define X86_XCOMP_AMX 1
> #define X86_XCOMP_XYZ1 2
> #define X86_XCOMP_XYZ2 3
>
> is way simpler to understand IMO.

I'm thinking 2 makes most sense. Perhaps we could use the highest
feature number involved in the facility to denote it? The rationale
being that we don't have to invent yet another enumeration and it's
easier to figure out what's what.