question about RMP table fixups for kexec

question about RMP table fixups for kexec

[Dave Young]

Hi Ashish,

I'm reading the code about E820 tables related code,  I noticed with
below commit you updated all three e820 tabes including
e820_table_kexec and e820_table_firmware.
commit 400fea4b9651adf5d7ebd5d71e905f34f4e4e493
Author: Ashish Kalra <ashish.kalra@amd.com>
Date:   Fri Apr 26 00:43:18 2024 +0000

    x86/sev: Add callback to apply RMP table fixups for kexec

...

+       if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
+               pr_info("Reserving start/end of RMP table on a 2MB
boundary [0x%016llx]\n", pa);
+               e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM,
E820_TYPE_RESERVED);
+               e820__range_update_table(e820_table_kexec, pa,
PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+               e820__range_update_table(e820_table_firmware, pa,
PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+       }
+}

A question here is, have you tried only updating e820_table and
e820_table_firmware?

I do not know much about SEV,  if you update e820_table, then the
memory range will be reserved in resouces, and kexec will not load
segments into the reserved ranges,  during the 2nd kernel bootup  your
code will be run again so I assume it is not necessary to pre-reserve
in e820_table_kexec and passing to 2nd kernel.

Could you confirm this question?

Thanks
Dave


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: question about RMP table fixups for kexec

[Kalra, Ashish]

Hi Dave,

On 9/14/2024 6:08 AM, Dave Young wrote:
> Hi Ashish,
>
> I'm reading the code about E820 tables related code,  I noticed with
> below commit you updated all three e820 tabes including
> e820_table_kexec and e820_table_firmware.
> commit 400fea4b9651adf5d7ebd5d71e905f34f4e4e493
> Author: Ashish Kalra <ashish.kalra@amd.com>
> Date:   Fri Apr 26 00:43:18 2024 +0000
>
>     x86/sev: Add callback to apply RMP table fixups for kexec
>
> ...
>
> +       if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
> +               pr_info("Reserving start/end of RMP table on a 2MB
> boundary [0x%016llx]\n", pa);
> +               e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM,
> E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_kexec, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_firmware, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +       }
> +}
>
> A question here is, have you tried only updating e820_table and
> e820_table_firmware?
>
> I do not know much about SEV,  if you update e820_table, then the
> memory range will be reserved in resouces, and kexec will not load
> segments into the reserved ranges,  during the 2nd kernel bootup  your
> code will be run again so I assume it is not necessary to pre-reserve
> in e820_table_kexec and passing to 2nd kernel.
>
> Could you confirm this question?

Yes, that is true but e820_table_kexec is passed on to the incoming kexec kernel as part of the boot params, so that will be the initial e820 memory map for the incoming kernel and to be safe we also modify the e820_table_kexec.

We have already observed memblock allocating memory from the initial e820 map before the above fixups modifies e820 tables for the 1st kernel and then this memblock memory getting allocated to guest and causing RMPUPDATE issues, as from the issue reported and fixed below:

[PATCH] x86/sev: ensure that RMP table fixups are reserved for memblock - Ashish Kalra (kernel.org) <https://lore.kernel.org/lkml/20240815221630.131133-1-Ashish.Kalra@amd.com/>

Therefore, it should be safer to have the initial e820 memory map being passed to the incoming/2nd kernel already have the fixups in it.

Thanks, Ashish


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec