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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jun 12, 2026 at 11:27:38AM +0200, Jan Beulich wrote:
> 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?

Hm, yes, I've fixed the instance below, but not the one here.

> > 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>

Thanks.

I will run a CI pre-commit loop and push it today if it's all fine.

Roger.