Received-SPF: pass (google.com: domain of linux-kernel+bounces-125065-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date: Fri, 29 Mar 2024 14:30:37 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Pavin Joseph <me@pavinjoseph.com>
Cc: Steve Wahl <steve.wahl@hpe.com>,
	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>,
	stable@vger.kernel.org, Eric Hagberg <ehagberg@gmail.com>,
	Simon Horman <horms@verge.net.au>,
	Eric Biederman <ebiederm@xmission.com>,
	Dave Young <dyoung@redhat.com>, Sarah Brofeldt <srhb@dbc.dk>,
	Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>,
	Hou Wenlong <houwenlong.hwl@antgroup.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Baoquan He <bhe@redhat.com>, Yuntao Wang <ytcoode@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v4] x86/mm/ident_map: On UV systems, use gbpages only
 where full GB page should be mapped.
Message-ID: <ZgbCfVPvWroCnGE4@gmail.com>
References: <20240328160614.1838496-1-steve.wahl@hpe.com>
 <ZgZqhWoRZoq5tJoU@gmail.com>
 <47302624-6466-41a7-85db-f6872d58a4d2@pavinjoseph.com>
 <ZgZ4qlbncvxhboQ0@gmail.com>
 <be5982f8-3928-455e-969c-1e4c419d80a2@pavinjoseph.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <be5982f8-3928-455e-969c-1e4c419d80a2@pavinjoseph.com>


* Pavin Joseph <me@pavinjoseph.com> wrote:

> On 3/29/24 13:45, Ingo Molnar wrote:
> > Just to clarify, we have the following 3 upstream (and soon to be upstream) versions:
> > 
> >   v1: pre-d794734c9bbf kernels
> >   v2: d794734c9bbf x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
> >   v3: c567f2948f57 Revert "x86/mm/ident_map: Use gbpages only where full GB page should be mapped."
> > 
> > Where v1 and v3 ought to be the same in behavior.
> > 
> > So how does the failure matrix look like on your systems? Is my
> > understanding accurate:

> Slight correction:
> 
>    regular boot  | regular kexec | nogbpages boot | nogbpages kexec boot
> -----------------|---------------|----------------|------------------
> v1:       OK     | OK            | OK             | FAIL
> v2:       OK     | FAIL          | OK             | FAIL

Thanks!

So the question is now: does anyone have a theory about in what fashion 
the kexec nogbpages bootup differs from the regular nogbpages bootup to 
break on your system?

I'd have expected the described root cause of the firmware not properly 
enumerating all memory areas that need to be mapped to cause trouble on 
regular, non-kexec nogbpages bootups too. What makes the kexec bootup 
special to trigger this crash?

	Ingo