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

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

On 4/2/2024 12:06 PM, Kalra, Ashish wrote:
> On 4/2/2024 11:34 AM, bp@kernel.org wrote:
>
>> From: Borislav Petkov <bp@alien8.de>
>>
>> On Tue, Apr 02, 2024 at 10:54:50AM -0500, Tom Lendacky wrote:
>>> There's no requirement from a hardware/RMP usage perspective that 
>>> requires a
>>> 2MB alignment, so BIOS is not doing anything wrong. The problem occurs
>>> because kexec is initially using 2MB mappings that overlap the start 
>>> and/or
>>> end of the RMP which then results in an RMP fault when memory within 
>>> one of
>>> those 2MB mappings, that is not part of the RMP, is referenced.
>> Then this explanation is misleading. And that whole bla about alignment
>> is nonsense either.
>>
>>> Additionally, we have BIOSes out there since Milan that don't do 
>>> this 2MB
>>> alignment. And do you really trust that BIOS will do this properly 
>>> all the
>>> time?
>> I don't trust the BIOS to do anything properly.
>>
>> So why isn't the fix for this simply to reserve the space for the RMP
>> table to start at 2M page - even if it doesn't - and to cover the last
>> chunk *also* with a 2M page and be done with it?
>
> But, it is the BIOS which reserves the space for the RMP table.
>
> And if you mean the reservation in the kernel page tables (directmap) 
> then that will not help as kexec uses it's own identity mapped page 
> tables.
>
>>
>> Not this silly overriding dance.
>
> This overriding dance is required to fixup all the three kexec tables, 
> as there is no interface/API available to do modifications/fixups in 
> all the three possible kexec tables.
>
I meant the three e820 tables out of which two are used for kexec, the 
e820_table_firmware and e820_table_kexec.

Thanks, Ashish

>
>> Thx.
>>