Re: [PATCH v4 6/8] L1TFv4 3

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 9 May 2018, speck for ak_at_linux.intel.com wrote:
> Since this needs to clear a feature bit that has been forced
> earlier add a special "unforce" macro that supports this.

There is no reason to add yet another macro to the cpu feature maze. The
right thing to do is to clear the forced bit from setup_clear_cpu_cap().

> +static __init void check_maxpa_memory(void)
> +{
> +	u64 len;
> +
> +	if (!boot_cpu_has(X86_BUG_L1TF))
> +		return;
> +
> +	len = BIT_ULL(boot_cpu_data.x86_phys_bits - 1) - 1;

Please name that variable max_pa

> +
> +	/*
> +	 * This is extremely unlikely to happen because systems near always have far

s/near/almost/

> +	 * more MAX_PA than DIMM slots.

That makes no sense, What has MAX_PA to do with the number of DIMM slots?

MAX_PA is the maximum physical address at least that what it has been used
for so far. So obviously MAX_PA is always larger than the number of DIMM
slots....

> +	 */
> +	if (e820__mapped_any(len, ULLONG_MAX - len,
> +				     E820_TYPE_RAM)) {

This line break is required becasue ... the line has been copied from an
indented block ...

Thanks,

	tglx