On 3/24/21 1:03 PM, Dave Hansen wrote: >> diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h >> index 10b1de500ab1..107f9d947e8d 100644 >> --- a/arch/x86/include/asm/trap_pf.h >> +++ b/arch/x86/include/asm/trap_pf.h >> @@ -12,6 +12,7 @@ >> * bit 4 == 1: fault was an instruction >> fetch >> * bit 5 == 1: protection keys block access >> * bit 15 == 1: SGX MMU page-fault >> + * bit 31 == 1: fault was an RMP violation >> */ >> enum x86_pf_error_code { >> X86_PF_PROT = 1 << 0, >> @@ -21,6 +22,7 @@ enum x86_pf_error_code { >> X86_PF_INSTR = 1 << 4, >> X86_PF_PK = 1 << 5, >> X86_PF_SGX = 1 << 15, >> + X86_PF_RMP = 1ull << 31, >> }; > Man, I hope AMD and Intel are talking to each other about these bits. :) > > Either way, this is hitting the limits of what I know about how enums > are implemented. I had internalized that they are just an 'int', but > that doesn't seem quite right. It sounds like they must be implemented > using *an* integer type, but not necessarily 'int' itself. > > Either way, '1<<31' doesn't fit in a 32-bit signed int. But, gcc at > least doesn't seem to blow the enum up into a 64-bit type, which is nice. > > Could we at least start declaring these with BIT()?
Sure, I can bit the BIT() macro to define the bits. Do you want me to update all of the fault codes to use BIT() or just the one I am adding in this patch ?