Re: [PATCH 2/2] x86/mm: Do not lose cpuinfo_x86:x86_phys_bits adjustment

[Thomas Gleixner]

On Thu, 15 Mar 2018, Kirill A. Shutemov wrote:

> Some features (Intel MKTME, AMD SME) may reduce number of effectively

May? They fricking reduce the number of bits.

> available physical address bits. We adjust x86_phys_bits accordingly.
> 
> But if get_cpu_cap() got called more than one time we may lose this
> information.

We may? Dammit, I asked you more than once to stop writing fairy
tales. Changelogs are about facts and not about may/could or whatever. And
not WE lose the information, the information gets overwritten by the
subsequent invocation of get_cpu_cap().

> That's exactly what happens in setup_pku(): it gets called after
> detect_tme() and x86_phys_bits gets overwritten.
> 
> Add x86_phys_bits_adj which stores by how many bits we should reduce
> x86_phys_bits comparing to what CPUID returns.

That's just sloppy, really.

The real question is: Why on earth is get_cpu_cap() updating the 0x80000008
leaf information again after the first initialization?

If there is no reason to do so, then this needs to be taken out of
get_cpu_caps().

If there is a reason, then this wants to be explained proper.

This 'add some duct tape' mode has to stop. The cpu feature detection is
messy enough already, there is no need to add more to it unless there is a
real compelling reason.

Thanks,

	tglx