Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1579268

Re: [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size MSR

From Thomas Gleixner <tglx@linutronix.de>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size MSR
Date 2017-02-12 20:40 +0100
Message-ID <ta8a6-1S5-23@gated-at.bofh.it> (permalink)
References <t6cvD-4hs-7@gated-at.bofh.it> <t6cvE-4hs-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 1 Feb 2017, Dave Hansen wrote:
> +/*
> + * The MPX tables change sizes based on the size of the virtual
> + * (aka. linear) address space.  There is an MSR to tell the CPU
> + * whether we want the legacy-style ones or the larger ones when
> + * we are running with an eXtended virtual address space.
> + */
> +static inline void switch_mpx_bd(struct mm_struct *prev, struct mm_struct *next)
> +{
> +	/*
> +	 * Note: there is one and only one bit in use in the MSR
> +	 * at this time, so we do not have to be concerned with
> +	 * preserving any of the other bits.  Just write 0 or 1.
> +	 */
> +	u32 IA32_MPX_LAX_ENABLE_MASK = 0x00000001;
> +
> +	/*
> +	 * Avoid the MSR on CPUs without MPX, obviously:
> +	 */
> +	if (!cpu_feature_enabled(X86_FEATURE_MPX))
> +		return;
> +	/*
> +	 * FIXME: do we want a check here for the 5-level paging
> +	 * CR4 bit or CPUID bit, or is the mawa check below OK?
> +	 * It's not obvious what would be the fastest or if it
> +	 * matters.
> +	 */

Well, you could use a static key which is enabled when 5 level paging and
MPX is enabled.

> +	/*
> +	 * Avoid the relatively costly MSR if we are not changing
> +	 * MAWA state.  All processes not using MPX will have a
> +	 * mpx_mawa_shift()=0, so we do not need to check
> +	 * separately for whether MPX management is enabled.
> +	 */
> +	if (likely(mpx_bd_size_shift(prev) == mpx_bd_size_shift(next)))
> +		return;

So this switches back unconditionally if the previous task was using the
large tables even if the next task is not using MPX at all. It's probably a
non issue.

Thanks,

	tglx

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC][PATCH 0/7] x86, mpx: Support larger address space (MAWA) (v2) Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
  [RFC][PATCH 1/7] x86, mpx: introduce per-mm MPX table size tracking Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
  [RFC][PATCH 3/7] x86, mpx: extend MPX prctl() to pass in size of bounds directory Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
    Re: [RFC][PATCH 3/7] x86, mpx: extend MPX prctl() to pass in size  of bounds directory Thomas Gleixner <tglx@linutronix.de> - 2017-02-12 20:20 +0100
  [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size MSR Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
    Re: [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size  MSR Thomas Gleixner <tglx@linutronix.de> - 2017-02-12 20:40 +0100
  [RFC][PATCH 7/7] x86, mpx: update MPX selftest to test larger bounds dir Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
  [RFC][PATCH 6/7] x86, mpx, selftests: Use prctl header instead of magic numbers Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
  [RFC][PATCH 5/7] x86, mpx: shrink per-mm MPX data Dave Hansen <dave.hansen@linux.intel.com> - 2017-02-02 00:30 +0100
    Re: [RFC][PATCH 5/7] x86, mpx: shrink per-mm MPX data Thomas Gleixner <tglx@linutronix.de> - 2017-02-12 23:50 +0100

csiph-web