Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in asm/stubs.h

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 16/05/2025 2:41 pm, Jan Beulich wrote:
> On 16.05.2025 15:33, Andrew Cooper wrote:
>> Very few files need the stubs.  Move the infrastructure out of
>> processor.h and config.h into a new stubs.h, and adjust the includes
>> accordingly.
>>
>> Make the per-cpu struct stubs be read mostly; they're unmodified
>> during the uptime of the CPU, and move them into smpboot.c seeing as
>> that's where they're allocated and freed.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

> with one possible suggestion:
>
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/stubs.h
>> @@ -0,0 +1,37 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef X86_ASM_STUBS_H
>> +#define X86_ASM_STUBS_H
>> +
>> +/*
>> + * Xen has several per-cpu executable stubs which are written dynamically.
> This puts it pretty well. Yet in principle there may be further, perhaps
> entirely different stubs in the future. Hence stubs.h feels a little
> generic. What about exec-stubs.h?

stubs is quite generic; in fact, that was my feedback for struct stubs.

There is something to be said for the header file to be the same as the
struct you want from it.

What did you have in mind for "different stubs"?  The only thing that
makes these special (i.e. not regular per-cpu data) is that we need an
executable mapping of them.  So, while I think it's reasonably likely
that we'll gain other uses (although, we're losing LSTAR/CSTAR when FRED
is enabled), I'm less certain what non-executable stubs would look like.

~Andrew