[MODERATED] Re: [PATCH v5 6/8] L1TFv4 4

[Andi Kleen <ak@linux.intel.com>]

On Wed, May 23, 2018 at 11:04:38PM -0500, speck for Josh Poimboeuf wrote:
> > index 2c0bd38a44ab..ffb178fe6356 100644
> > --- a/arch/x86/kernel/cpu/cpuid-deps.c
> > +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> > @@ -118,4 +118,5 @@ void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
> >  void setup_clear_cpu_cap(unsigned int feature)
> >  {
> >  	do_clear_cpu_cap(NULL, feature);
> > +	clear_bit(feature, (unsigned long *)cpu_caps_set);
> 
> The caps code is a jungle, so who knows... but isn't this what
> cpu_caps_cleared is for?  Aren't the cpu_caps_set bits supposed to stay
> set (for some mysterious reason)?

Set beats cleared without this change. I tested it.

> 
> AFAICT, the cpu_caps_cleared bit already gets set in do_clear_cpu_cap()
> -> clear_feature().  So I don't see that clearing the cpu_caps_set bit
> actually accomplishes anything on top of that.

The patch is needed.

> 
> >  }
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 443e31c33fa6..99155e9b28c4 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -785,7 +785,26 @@ static void __init trim_low_memory_range(void)
> >  {
> >  	memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
> >  }
> > -	
> > +
> > +static __init void check_maxpa_memory(void)
> > +{
> > +	u64 half_pa;
> > +
> > +	if (!boot_cpu_has(X86_BUG_L1TF))
> > +		return;
> > +
> > +	half_pa = (u64)l1tf_pfn_limit() << PAGE_SHIFT;
> > +
> > +	/*
> > +	 * This is extremely unlikely to happen because almost all systems have far
> > +	 * more MAX_PA/2 than DIMM slots.
> 
> s/DIMM slots/actual RAM/?

It's the same in this case.

> 
> Also is MAX_PA a macro or something else?  I don't see it in the code

It's a logical construct but doesn't correspond to a macro in the code.

-Andi