Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in asm/stubs.h
On 16.05.2025 15:49, Andrew Cooper wrote: > On 16/05/2025 2:41 pm, Jan Beulich wrote: >> On 16.05.2025 15:33, Andrew Cooper wrote: >>> --- /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. A while after having written my reply, I started wondering myself. Likely we wouldn't normally call anything non-executable a "stub", so please disregard my suggestion. Jan
Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in asm/stubs.h
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 > Acked-by: Jan Beulich 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
Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in asm/stubs.h
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 Acked-by: Jan Beulich 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? Jan
