Re: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec.

[Mike Rapoport <rppt@kernel.org>]

Hi,

(sorry for jumping really late, I've just found this accidentally)

On Fri, Apr 26, 2024 at 09:56:25AM -0500, Kalra, Ashish wrote:
> On 4/26/2024 7:58 AM, Borislav Petkov wrote:
> 
> > On Wed, Apr 24, 2024 at 06:48:08PM -0500, Kalra, Ashish wrote:
> > > This callback needs to be invoked as part of setup_arch() as it needs e820
> > > table to be setup in e820__memory_setup() before the callback is invoked and
> > > snp_init() is called from sme_enable() in kernel/head_64.S (startup_64),
> > > which is much before start_kernel() -> setup_arch() is invoked.
> > So?
> > 
> > snp_init() still runs before e820__memory_setup(). So what's stopping
> > you?
> 
> As i have already explained above, snp_init() runs before
> e820__memory_setup() so we can't invoke this callback in snp_init() as e820
> tables have still not been setup. Again to summarize, the e820 tables are
> setup in e820__memory_setup() which runs after snp_init().

I agree that snp_fixup_e820_tables() should run after e820__memory_setup(),
but I wonder if it's ok for it to run *after* e820__memblock_setup().

At the very least making changes to e820 table after they were translated
to memblock creates inconsistency between the e820 and core mm views of the
memory. 

So I wonder what would happen if the memory from the problematic chunk was
allocated by kernel rather than by kexec? Couldn't it cause RMP fault?

-  
Sincerely yours,
Mike.