Re: [PATCH] xen/arm: skip holes in physical address space when setting up frametable

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/04/2026 10:11 am, Michal Orzel wrote:
> Refactor setup_frametable_mappings() into init_frametable(), modeled
> after x86's implementation. Instead of mapping one contiguous frametable
> covering ram_start to ram_end (including holes), iterate the
> pdx_group_valid bitmap to allocate and map frametable memory only for
> valid PDX groups, skipping gaps in the physical address space. At the
> moment we don't really take into account pdx_group_valid bitmap.
>
> This reduces memory consumption on systems with sparse RAM layouts by
> not allocating frametable entries for non-existent memory regions.
>
> A file-local pdx_to_page() override is needed because the generic macro
> in xen/include/xen/pdx.h does not account for ARM's non-zero
> frametable_base_pdx.
>
> Update the MPU implementation to match the new init_frametable()
> signature. Since MPU has no virtual address translation (ma == va),
> hole-skipping is not possible and the frametable remains a single
> contiguous allocation.
>
> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> ---
> We've been using this approach at AMD for a while now. Without this we would 
> not
> be able to boot some of our boards that have huge holes in the PA space, so I
> consider this patch a great improvement.
>
> Two things to consider as a follow-up in the future:
>  - change generic pdx_to_page, page_to_pdx to take into account offset that
>    on x86 is zero but on other arches it is not. The page list code is
>    for now unaffected because the offset cancels out,
>  - use the same on RISCV.

PPC also has frametable_base_pdx and a TODO saying "make this work". 
The header file however is horribly tangled and needs some work.

What I think we want is to include <asm/pdx.h> early (if it exists), and
allow it the option to define frametable_base_pdx, but with a common
fallback making it 0.

I think we also want to split out xen/pdx-{mask,offset}.h each taking
their respective chunk of the giant comment.  Possibly pdx-none.h too. 
This separates the unrelated algorithms, and puts their definitions next
to the comment explaining how it works.

~Andrew