Re: [PATCH v6 01/44] x86/mm: allocate the per-domain L3 in arch_domain_create()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.11.2026 23:13, George Dunlap wrote:
> init_xen_l4_slots() relies on d->arch.perdomain_l3_pg being non-NULL,
> or it will fill in a garbage value for slot 260.  Currently, this
> is allocated only implicitly, as a side effect of calling
> create_perdomain_mapping().  But depending on the specific
> circumstances, this may not happen until several hypercalls after the
> domain is created.  This is not robust: callers need to keep track of
> when exactly certain structures happen to be created to ensure that
> init_xen_l4_slots() operates properly.
> 
> Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at
> domain creation"), a PV domain gets its L3 with its first vCPU
> (pv_create_gdt_ldt_l1tab()).  Only mapcache_domain_init() makes it
> earlier, and release builds skip that unless memory hotplug is enabled
> or the host's memory reaches past the part of the directmap PV guests
> can see.  So in release builds on most hosts, an L4 that is promoted
> before XEN_DOMCTL_max_vcpus has created the domain's vCPUs gets a
> slot 260 entry made from a NULL page (0x803e900000000063).  libxl is
> unaffected: it creates the vCPUs before it builds or restores a domain.
> 
> Allocate it explicitly in arch_domain_create() instead.  Introduce
> allocate_perdomain_l3(), which will allocate a page with the
> appropriate parameters and zero it.  create_perdomain_mapping() now
> requires the L3 to exist, and BUG()s if it does not.
> 
> We return a pg rather than setting d->arch.perdomain_l3_pg directly,
> because later we'll use the same function to initialize the per-vCPU
> perdomain L3.
> 
> This removes the need to allocate it semi-implicitly (calling
> create_perdomain_mapping() with nr == 0) in hvm_domain_initialise().
> 
> Fixes: fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at domain 
> creation")
> Assisted-by: Claude Code:claude-opus-5-5
> Signed-off-by: George Dunlap <gwd@xxxxxxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>