Re: [PATCH for-4.22 v3] xen/x86: Change stub page allocation/free

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.06.2026 10:22, Roger Pau Monne wrote:
> From: Jason Andryuk <jason.andryuk@xxxxxxx>
> 
> Today the inline tracking of the stub page is problematic.  0xcc is used to
> indicate unused, but it is also a "clear value."  A !CONFIG_PV build or
> when running with FRED support will not populate the LSTAR/CSTAR stubs at
> CPU bringup.  If a CPU is then offlined, the stubs page will be freed as
> its content will be all 0xcc, regardless of the stubs page still begin
> referenced by other CPUs.
> 
> The new approach uses a global, CPU-indexed dynamically allocated array of
> stub addresses.  However, to handle NUMA aware allocations, we cannot
> allocate all the memory in advance because of the NUMA dependency.  Take
> advantage of the fact that Xen will attempt to contiguously pack CPUs on
> the same NUMA node (see normalise_cpu_order()), and on CPU bringup use the
> same stubs page the previous CPU did if suitable.  Note the code would
> still function properly even if CPUs from NUMA nodes are not contiguously
> packed, it just consumes more memory.
> 
> stub pages are no longer freed.  They remain referenced in the global

Nit: Didn't you mean to s/stub/Stub/ as per Andrew's comment?

> CPU-indexed array and are re-used if the CPU is re-onlined.
> 
> The stubs array doesn't have an explicit lock.  During boot it's accessed
> single threaded.  During runtime, &cpu_add_remove_lock serializes access.
> 
> Fixes: 7a66ac8d1633 ("x86: move syscall trampolines off the stack")
> Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Tested-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> Reviewed-by: Jason Andryuk <jason.andryuk@xxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan