Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Thu, 28 Sep 2023 17:04:05 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     "Compostella, Jeremy" <jeremy.compostella@intel.com>
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v2 1/2] x86/cpu/intel: Fix MTRR verification for TME
 enabled platforms
Message-ID: <20230928150405.GCZRWV5bjjUuWof3HQ@fat_crate.local>
References: <87il7xu7ki.fsf@jcompost-mobl.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87il7xu7ki.fsf@jcompost-mobl.amr.corp.intel.com>
Precedence: bulk

On Mon, Sep 25, 2023 at 05:00:45PM -0700, Compostella, Jeremy wrote:
> On TME enabled platform, BIOS publishes MTRR taking into account Total
> Memory Encryption (TME) reserved bits.
> 
> generic_get_mtrr() performs a sanity check of the MTRRs relying on the
> `phys_hi_rsvd' variable which is set using the cpuinfo_x86 structure
> `x86_phys_bits' field.  But at the time the generic_get_mtrr()
> function is ran the `x86_phys_bits' has not been updated by
> detect_tme() when TME is enabled.
> 
> Since the x86_phys_bits does not reflect yet the real maximal physical
> address size yet generic_get_mtrr() complains by logging the following
> messages.
> 
>     mtrr: your BIOS has configured an incorrect mask, fixing it.
>     mtrr: your BIOS has configured an incorrect mask, fixing it.
>     [...]
> 
> For `x86_phys_bits' to be updated before generic_get_mtrr() runs, this
> patch moves the detect_tme() call from init_intel() to

Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.

Also, do

$ git grep 'This patch' Documentation/process

for more details.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette