Received-SPF: pass (google.com: domain of linux-kernel+bounces-121329-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Steve Wahl <steve.wahl@hpe.com>
Cc: Russ Anderson <rja@hpe.com>,  Ingo Molnar <mingo@kernel.org>,  Dave
 Hansen <dave.hansen@linux.intel.com>,  Andy Lutomirski <luto@kernel.org>,
  Peter Zijlstra <peterz@infradead.org>,  Thomas Gleixner
 <tglx@linutronix.de>,  Ingo Molnar <mingo@redhat.com>,  Borislav Petkov
 <bp@alien8.de>,  x86@kernel.org,  "H. Peter Anvin" <hpa@zytor.com>,
  linux-kernel@vger.kernel.org,  Linux regressions mailing list
 <regressions@lists.linux.dev>,  Pavin Joseph <me@pavinjoseph.com>,
  stable@vger.kernel.org,  Eric Hagberg <ehagberg@gmail.com>,  Simon Horman
 <horms@verge.net.au>,  Dave Young <dyoung@redhat.com>,  Sarah Brofeldt
 <srhb@dbc.dk>,  Dimitri Sivanich <sivanich@hpe.com>
References: <20240322162135.3984233-1-steve.wahl@hpe.com>
	<ZgABC1oQ9YJW6Bw3@gmail.com> <20240325020334.GA10309@hpe.com>
	<87o7b273p2.fsf@email.froward.int.ebiederm.org>
	<ZgHTXvCQr6ycbVzp@swahl-home.5wahls.com>
Date: Wed, 27 Mar 2024 07:57:52 -0500
In-Reply-To: <ZgHTXvCQr6ycbVzp@swahl-home.5wahls.com> (Steve Wahl's message of
	"Mon, 25 Mar 2024 14:41:18 -0500")
Message-ID: <87r0fv6ddb.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH] x86/mm/ident_map: Use full gbpages in identity maps
 except on UV platform.

Steve Wahl <steve.wahl@hpe.com> writes:

> On Mon, Mar 25, 2024 at 10:04:41AM -0500, Eric W. Biederman wrote:
>> Russ Anderson <rja@hpe.com> writes:
>> > Steve can certainly merge his two patches and resubmit, to replace the
>> > reverted original patch.  He should be on in the morning to speak for
>> > himself.
>> 
>> I am going to push back and suggest that this is perhaps a bug in the
>> HPE UV systems firmware not setting up the cpus memory type range
>> registers correctly.
>> 
>> Unless those systems are using new fangled cpus that don't have 16bit
>> and 32bit support, and don't implement memory type range registers,
>> I don't see how something that only affects HPE UV systems could be
>> anything except an HPE UV specific bug.
>
> Eric,
>
> I took the time to communicate with others in the company who know
> this stuff better than I do before replying on this.
>
> One of the problems with using the MTRRs for this is that there are
> simply not enough of them.  The MTRRs size/alignment requirements mean
> that more than one entry would be required per reserved region, and we
> need one reserved region per socket on systems that currently can go
> up to 32 sockets.  (In case you would think to ask, the reserved
> regions also cannot be made contiguous.)
>
> So MTRRs will not work to keep speculation out of our reserved memory
> regions.
>
> Let me know if you need more information from us on this.

Thanks for this.

Do you know if there are enough MTRRs for the first 4GB?

I am curious if kexec should even consider going into 32bit mode without
page tables or even into 16bit mode on such a system.  Or if such a
system will always require using page tables.

If you don't have enough MTRRs on a big NUMA system I think it is
perfectly understandable, to need to use the page tables.

Please include this the fact that splitting GBpages is necessary because
of a lack of MTRRs in the change description.

Given that it is the lack of MTRRs on a large NUMA system that make the
change necessary.   The goes from a pure bug fix change to a change to
accommodate systems without enough MTRRs.

That information makes it more understandable why older systems (at
least in the case of kexec) might not be ok with the change.  As for
older systems their MTRRs are sufficient and thus they can use fewer
page table entries.  Allowing for use of larger TLB entries.


Eric