lkml.org 
[lkml]   [2017]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2017-02-12 20:06    [W:0.084 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site