Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v11 15/29] x86/arch_prctl: Create ARCH_SET_STATE_ENABLE/ARCH_GET_STATE_ENABLE | Date | Tue, 05 Oct 2021 14:27:25 +0200 |
| |
On Tue, Oct 05 2021 at 13:23, Peter Zijlstra wrote: > 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.
That makes sense. So the above would be:
#define X86_XCOMP_AMX 18 (implies 17) #define X86_XCOMP_XYZ1 19 #define X86_XCOMP_XYZ2 20 (implies 19)
Thanks,
tglx
| |