Re: [PATCH] x86/sev: Apply RMP table fixups for kexec.

From: Kalra, Ashish
Date: Tue Apr 02 2024 - 17:31:47 EST



On 4/2/2024 4:20 PM, Borislav Petkov wrote:
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 main issue is there is no API interface available to do that, i will need to add new API interfaces to update the e820_table_kexec and e820_table_firmware and then will that be acceptable for a use case which can be handled via a platform specific quirk ?
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?

Yes exactly, that's what the above comment means.

 That's why the above commit message says "may".


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

My point is that we always keep the RMP table memory reserved regardless of SNP enablement, so these are simply fixups/adjustments on top of that reservation.

Thanks, Ashish

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...