Received-SPF: pass (google.com: domain of linux-kernel+bounces-128720-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 2 Apr 2024 23:20:09 +0200
From: Borislav Petkov <bp@alien8.de>
To: "Kalra, Ashish" <ashish.kalra@amd.com>
Cc: bp@kernel.org, thomas.lendacky@amd.com, linux-kernel@vger.kernel.org,
	linux-tip-commits@vger.kernel.org, michael.roth@amd.com,
	x86@kernel.org
Subject: Re: [PATCH] x86/sev: Apply RMP table fixups for kexec.
Message-ID: <20240402212009.GEZgx2iZC_Plx-ajKW@fat_crate.local>
References: <2ab14f6f-2690-056b-cf9e-38a12dafd728@amd.com>
 <20240402163412.19325-1-bp@kernel.org>
 <6f0d2ccf-243c-4073-a470-21e2f404595a@amd.com>
 <359264a1-e4ef-438c-8f24-32848e131272@amd.com>
 <20240402174540.GAZgxERNxsRJUCb1yp@fat_crate.local>
 <37321af9-aee4-4ba6-81ac-0df4cef38644@amd.com>
 <20240402185039.GBZgxTfwvEP45OxVjm@fat_crate.local>
 <8daf448f-eb52-4b1f-9f98-099a83665321@amd.com>
 <20240402202118.GCZgxovu-pgPKYvner@fat_crate.local>
 <6fdb98f8-b4e2-474d-b8e9-c3092e77e56e@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6fdb98f8-b4e2-474d-b8e9-c3092e77e56e@amd.com>

On Tue, Apr 02, 2024 at 04:00:03PM -0500, Kalra, Ashish wrote:
> The main issue with doing that in snp_rmptable_init() is that there is no
> e820 API interfaces available to update the e820_table_kexec and
> e820_table_firmware and e820_table_firmware has already been exposed to
> sysfs.

And?

You can't change it later? Tried?

> The e820 API only exports e820__range_update() which *only* fixes
> e820_table.
> 
> The important point to note here is that in most cases BIOS would have
> reserved RMP table start and end aligned to 2M boundary and setup the e820
> table which the BIOS passes to the kernel as such,

So what was this "RMP table start and end physical range may not be
aligned to 2MB" in your commit message?

/me is completely confused now.

Or does "most cases" mean that there can be cases where the RMP table
placement in the BIOS is not 2M aligned and then the kexec kernel could
try to allocate from within that chunk and there's RMP faults?

And you want to allocate those chunks up to the 2M boundary
unconditionally, regardless of SNP enablement?

Now look at your original commit message and tell me how much of what
came out on this thread, was in it?

Not a lot, I'd say...

-- 
Regards/Gruss,
    Boris.

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