Messages in this thread | | | Date | Sun, 12 Feb 2017 20:05:53 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [RFC][PATCH 2/7] x86, mpx: update MPX to grok larger bounds tables |
| |
On Wed, 1 Feb 2017, Dave Hansen wrote: > /* > - * The upper 28 bits [47:20] of the virtual address in 64-bit > - * are used to index into bounds directory (BD). > + * The uppermost bits [56:20] of the virtual address in 64-bit > + * are used to index into bounds directory (BD). On processors > + * with support for smaller virtual address space size, the "56" > + * is obviously smaller.
... space size, the upper limit is adjusted accordingly.
Or something like that,
> +/* > + * Note: size of tables on 64-bit is not constant, so we have no > + * fixed definition for MPX_BD_NR_ENTRIES_64. > + * > + * The 5-Level Paging Whitepaper says: "A bound directory > + * comprises 2^(28+MAWA) 64-bit entries." Since MAWA=0 in > + * legacy mode: > + */ > +#define MPX_BD_LEGACY_NR_ENTRIES_64 (1UL<<28)
(1UL << 28) please
> > +static inline int mpx_bd_size_shift(struct mm_struct *mm) > +{ > + return mm->context.mpx_bd_shift; > +}
Do we really need that helper?
> static inline unsigned long mpx_bd_size_bytes(struct mm_struct *mm) > { > - if (is_64bit_mm(mm)) > - return MPX_BD_SIZE_BYTES_64; > - else > + if (!is_64bit_mm(mm)) > return MPX_BD_SIZE_BYTES_32; > + > + /* > + * The bounds directory grows with the address space size. > + * The "legacy" shift is 0. > + */ > + return MPX_BD_BASE_SIZE_BYTES_64 << mpx_bd_shift_shift(mm);
shift_shift. I wonder how that compiles...
Looks good otherwise.
Thanks,
tglx
| |