Re: [PATCH v3 1/1] xen/arm: populate a default P2M pool for new domains

[Julien Grall <julien@xxxxxxx>]

Hi Julian,

On 30/10/2026 09:49, Julian Vetter wrote:
> On x86, a domain can be populated directly after the
> XEN_DOMCTL_createdomain call. Sizing the pool is thus an optional tuning
> step for the toolstack (libxl: "the Xen minimum is for safety, not
> performance").
>
> On ARM however, the P2M pool of a non-hardware domain starts empty. So,
> any toolstack must size the pool before populating the domain's physmap,
> otherwise no P2M tables can be allocated. This is an ARM specific step,
> which every toolstack has to know about.
Can you explain why this is a problem to modify the toolstacks? We 
designed the domain creation specifically to avoid the pre-allocating 
the P2M pool.
Furthermore, you say you want to be consistent with x86 but...

> Instead, populate a default pool of 256 pages (1MByte) in p2m_init(),
> matching what x86 HAP does in hap_enable(). The size is intentionally
> fixed, because p2m_init() isn't preemptible, so the allocation must stay
> bounded. Then dom0less and libxl set the full size, as they do today.
>
> Skip the hardware domain, which has no dedicated P2M pool. Also skip LLC
> colored setups, as the domain's colors are only configured after domain
> creation, so the pool pages would be allocated with the default colors.
... on Arm we will have inconsistency between the various configuration.

My preference is we modify the toolstack rather adding, what seems 
random, 256 pages at domain creation.
> Signed-off-by: Julian Vetter <julian.vetter@xxxxxxxxxx>
> ---
> Changes in v3:
> - Use a fixed default of 256 pages, as x86 HAP does
> - Drop the domain_p2m_default_kb() helper and the dom0less change
> - Adapt the commit message to explain why a fixed size is used
>
> Changes in v2:
> - Size the default pool based on the exisiting formula
> - Rewrite commit message to explain why a default pool is desirable
> ---
>   xen/arch/arm/mmu/p2m.c | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
>
> diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
> index 70d7c9fed9..9579e905d8 100644
> --- a/xen/arch/arm/mmu/p2m.c
> +++ b/xen/arch/arm/mmu/p2m.c
> @@ -3,6 +3,7 @@
>   #include <xen/domain_page.h>
>   #include <xen/ioreq.h>
>   #include <xen/lib.h>
> +#include <xen/llc-coloring.h>
>   #include <xen/sched.h>
>   #include <xen/softirq.h>
>   
> @@ -1555,6 +1556,26 @@ int p2m_init(struct domain *d)
>       if ( rc )
>           return rc;
>   
> +    /*
> +     * Populate a default of 256 pages (1MB) to the P2M pages pool here, as
> +     * x86 HAP does. So, the domain is usable without the pool being sized
> +     * first. The toolstack, or dom0less, still sets the full size later,
> +     * taking the domain's RAM into account. A fixed size keeps this
> +     * non-preemptible allocation bounded, independent of the number of vCPUs.
> +     *
> +     * Skip the hardware domain, which has no dedicated P2M pool, and LLC
> +     * colored setups, as the domain's colors are only configured after domain
> +     * creation.
> +     */
> +    if ( !is_hardware_domain(d) && !llc_coloring_enabled )
> +    {
> +        spin_lock(&d->arch.paging.lock);
> +        rc = p2m_set_allocation(d, 256, /* can_preempt */ false);
> +        spin_unlock(&d->arch.paging.lock);
> +        if ( rc )
> +            return rc;
> +    }
Regardless what I wrote above, have you confirmed that the rest of the 
logic will be able to cope in case of failure? At least 4dbcb0653621 
("xen/arm: Defer GICv2 CPU interface mapping until the first access") 
use it as an argument to not have a default pool.
Cheers,

--
Julien Grall