Re: [PATCH v2] x86/sev: Apply the RMP table e820 fixups before memblock is populated

[Mike Rapoport <rppt@kernel.org>]

On Tue, Oct 20, 2026 at 08:28:18PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> When the start and/or end of the RMP table is not 2MB aligned,
> snp_fixup_e820_tables() converts the 2MB chunk containing it from RAM to
> reserved in the e820 tables, so that it is never used by the kernel (or
> by a kexec-ed kernel) and SNP_INIT marks it HV-Fixed.
> 
> The fixups are done from mem_encrypt_setup_arch(), which runs after
> max_pfn has been computed and after e820__memblock_setup() has populated
> memblock from the e820 table. The RAM part of those chunks therefore
> remains in memblock.memory. Commit 88a921aa3c6b ("x86/sev: Ensure that
> RMP table fixups are reserved") dealt with one consequence of that, the
> chunks still being allocatable, by additionally reserving them in
> memblock, but memblock still describes them as memory.
> 
> That trips up the direct map setup. init_range_memory_mapping() maps the
> memblock.memory ranges, so the RAM part of a chunk gets mapped. When a
> subsequent, lower range is mapped, the trimming in phys_pmd_init() or
> phys_pud_init() consults e820 instead, finds no RAM in the 2MB (or 1GB)
> slot and clears the already populated entry. At boot this goes through
> set_pmd_safe()/set_pud_safe() and triggers:
> 
>   SEV-SNP: RMP table physical range [0x000000bf77900000 - 0x000000c037efffff]
>   SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000bf77800000]
>   SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000c037e00000]
>   ...
>   init_memory_mapping: [mem 0xbf60000000-0xbf778fffff]
>    [mem 0xbf60000000-0xbf777fffff] page 2M
>    [mem 0xbf77800000-0xbf778fffff] page 4k
>   init_memory_mapping: [mem 0xbf40000000-0xbf5fffffff] page 2M
>   WARNING: arch/x86/mm/init_64.c:89 at phys_pmd_init+0x389/0x4b0, CPU#0: swapper/0
>   Call Trace:
>    phys_pud_init
>    phys_p4d_init
>    __kernel_physical_mapping_init
>    init_memory_mapping
>    init_range_memory_mapping
>    init_mem_mapping
>    setup_arch
>    start_kernel
> 
> and leaks the page table page that hung off the cleared entry.
> 
> None of the fixups depend on memblock: the RMP table is probed and
> CC_ATTR_HOST_SEV_SNP is set from early_cpu_init(), and the segmented RMP
> case only needs early_memremap(). They do depend on the e820 tables,
> which are only built in e820__memory_setup() (which also populates
> e820_table_kexec), so the fixups cannot run any earlier than that.
> 
> Move them into a new mem_encrypt_fixup_e820() called from setup_arch()
> right after trim_bios_range(), before max_pfn is computed and memblock is
> populated, so that both are derived from the final e820 table, and
> finalize the table with e820__update_table(). mem_encrypt_setup_arch()
> keeps the SWIOTLB sizing, which needs the memblock-derived memory size and
> stays after e820__memblock_setup(). The memblock reservation is then no
> longer needed and is removed.

Although the commit message is a bit hard to parse, the idea makes sense to
me.

If we anyway have a range marked as E820_TYPE_RESERVED, just keep it
consistent with other E820_TYPE_RESERVED that never make it into
memblock.memory.
 
> Fixes: 400fea4b9651 ("x86/sev: Add callback to apply RMP table fixups for kexec")
> Co-developed-by: Shivank Garg <shivankg@amd.com>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

FWIW: 

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> v2:
>  - Route the fixup through a new mem_encrypt_fixup_e820() wrapper instead of
>    calling snp_fixup_e820_tables() directly from setup_arch().  This keeps
>    the memory-encryption specifics out of setup.c (no <asm/sev.h> there) and
>    alongside mem_encrypt_setup_arch() in the mem_encrypt layer.  No
>    functional change.
> 
>  arch/x86/include/asm/mem_encrypt.h |  2 ++
>  arch/x86/kernel/setup.c            |  1 +
>  arch/x86/mm/mem_encrypt.c          | 14 +++++++-------
>  arch/x86/virt/svm/sev.c            |  9 ++++-----
>  4 files changed, 14 insertions(+), 12 deletions(-)

-- 
Sincerely yours,
Mike.