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
