lkml.org 
[lkml]   [2021]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v11 15/29] x86/arch_prctl: Create ARCH_SET_STATE_ENABLE/ARCH_GET_STATE_ENABLE
Date
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

\
 
 \ /
  Last update: 2021-10-05 14:27    [W:5.014 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site