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

["Kalra, Ashish" <ashish.kalra@amd.com>]

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