Re: [PATCH] x86: invoke xenheap_max_mfn() unconditionally

[George Dunlap <gwd@xxxxxxxxxxxxxx>]

On Mon, Oct 12, 2026 at 12:12 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> Calling the function only conditionally can, when highmem_start isn't set
> and when hotplugged memory appears above the boundary where the "short"
> directmap ends, result in Xenheap allocations to yield memory which isn't
> accessible through the "short" directmap. Accesses from PV guest context
> would then either fault or access guest controlled memory.
>
> With this the bifurcation done by 88e3ed61642b ("x86/NUMA: make
> init_node_heap() respect Xen heap limit") can also be undone:
> end_boot_allocator() can be called from a single place, and system_state
> is bumped right afterwards.
>
> Fixes: adc5afbf1c70 ("x86: support up to 16Tb")
> Assisted-by: Claude Opus 5.5
> Reported-by: George Dunlap <gwd@xxxxxxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Reviewed-by: George Dunlap <gwd@xxxxxxxxxxxxxx>

I might note more strongly that the bifurcation is a robustness issue:
people checking for SYS_STATE_boot are specifically checking whether
the boot allocation regime is still in place.  I take it we're not
moving "system_state = SYS_STATE_boot" into end_boot_allocator() to
make it easier to see the major milestones in setup.c:__start_xen().

As an aside, Claude notes that highmem_start isn't clamped to 5TiB; in
theory if somebody put `highmem-start=6T` on the command-line, it
would cause problems.