xen/arch/arm/include/asm/nospec.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
While today they don't implement fencing in a way that would block
speculation, once/if they do they'll absolutely need to be inlined, even
if -fno-inline or -fno-early-inlining are passed.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
xen/arch/arm/include/asm/nospec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/include/asm/nospec.h b/xen/arch/arm/include/asm/nospec.h
index 51c7aea4f4..b84f8dff45 100644
--- a/xen/arch/arm/include/asm/nospec.h
+++ b/xen/arch/arm/include/asm/nospec.h
@@ -4,12 +4,12 @@
#ifndef _ASM_ARM_NOSPEC_H
#define _ASM_ARM_NOSPEC_H
-static inline bool evaluate_nospec(bool condition)
+static always_inline bool evaluate_nospec(bool condition)
{
return condition;
}
-static inline void block_speculation(void)
+static always_inline void block_speculation(void)
{
}
base-commit: 290959692726bed9a9404fbb151767dba9928c5b
--
2.43.0
On Tue, Oct 06, 2026 at 12:31:40PM +0200, Alejandro Vallejo wrote: > While today they don't implement fencing in a way that would block > speculation, once/if they do they'll absolutely need to be inlined, even > if -fno-inline or -fno-early-inlining are passed. FWIW, it's my understanding that -fno-early-inlining is not really relevant here; it disables the early inlining pass, but the late(r) one(s) is/are still present, so inlining will happen, just later in the compilation process. -fno-inline is indeed relevant here. Thanks, Roger.
On 06-Oct-26 12:31, Alejandro Vallejo wrote: > While today they don't implement fencing in a way that would block > speculation, once/if they do they'll absolutely need to be inlined, even > if -fno-inline or -fno-early-inlining are passed. > > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> but this should be done for Arm, RISCV and PPC at once in which case you can keep my tag for v2 # for Arm. ~Michal
On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: > > > On 06-Oct-26 12:31, Alejandro Vallejo wrote: > > While today they don't implement fencing in a way that would block > > speculation, once/if they do they'll absolutely need to be inlined, even > > if -fno-inline or -fno-early-inlining are passed. > > > > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> > Reviewed-by: Michal Orzel <michal.orzel@amd.com> > > but this should be done for Arm, RISCV and PPC at once in which case you can > keep my tag for v2 # for Arm. Neither RISCV nor PPC implement nospec.h today. Should I considered the R-by just settled for this patch? Cheers, Alejandro > > ~Michal
On 06-Oct-26 14:29, Alejandro Vallejo wrote: > On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: >> >> >> On 06-Oct-26 12:31, Alejandro Vallejo wrote: >>> While today they don't implement fencing in a way that would block >>> speculation, once/if they do they'll absolutely need to be inlined, even >>> if -fno-inline or -fno-early-inlining are passed. >>> >>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> >> Reviewed-by: Michal Orzel <michal.orzel@amd.com> >> >> but this should be done for Arm, RISCV and PPC at once in which case you can >> keep my tag for v2 # for Arm. > > Neither RISCV nor PPC implement nospec.h today. Should I considered the > R-by just settled for this patch? I'm not sure I understand. You wrote that they don't implement the header whereas I can see: arch/riscv/include/asm/nospec.h arch/ppc/include/asm/nospec.h hence my remark to fix all at once. ~Michal
On Wed Oct 7, 2026 at 2:00 PM CEST, Orzel, Michal wrote: > > > On 06-Oct-26 14:29, Alejandro Vallejo wrote: > > On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: > >> > >> > >> On 06-Oct-26 12:31, Alejandro Vallejo wrote: > >>> While today they don't implement fencing in a way that would block > >>> speculation, once/if they do they'll absolutely need to be inlined, even > >>> if -fno-inline or -fno-early-inlining are passed. > >>> > >>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> > >> Reviewed-by: Michal Orzel <michal.orzel@amd.com> > >> > >> but this should be done for Arm, RISCV and PPC at once in which case you can > >> keep my tag for v2 # for Arm. > > > > Neither RISCV nor PPC implement nospec.h today. Should I considered the > > R-by just settled for this patch? > I'm not sure I understand. You wrote that they don't implement the header > whereas I can see: > arch/riscv/include/asm/nospec.h > arch/ppc/include/asm/nospec.h > hence my remark to fix all at once. Bah, I was on a completely different baseline than I should've been. Even v1 doesn't apply cleanly. Let me prep a proper v2 then. Cheers, Alejandro > > ~Michal
On 06/10/2026 11:45 am, Orzel, Michal wrote: > > On 06-Oct-26 12:31, Alejandro Vallejo wrote: >> While today they don't implement fencing in a way that would block >> speculation, once/if they do they'll absolutely need to be inlined, even >> if -fno-inline or -fno-early-inlining are passed. >> >> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> > Reviewed-by: Michal Orzel <michal.orzel@amd.com> > > but this should be done for Arm, RISCV and PPC at once in which case you can > keep my tag for v2 # for Arm. I previously had a patch series which made this all common, for these kinds of reasons. I think I'd prefer to kick that over the line, than to keep on taking micro-bugfixes like this. ~Andrew
On Tue Oct 6, 2026 at 12:51 PM CEST, Andrew Cooper wrote:
> On 06/10/2026 11:45 am, Orzel, Michal wrote:
> >
> > On 06-Oct-26 12:31, Alejandro Vallejo wrote:
> >> While today they don't implement fencing in a way that would block
> >> speculation, once/if they do they'll absolutely need to be inlined, even
> >> if -fno-inline or -fno-early-inlining are passed.
> >>
> >> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> > Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> >
> > but this should be done for Arm, RISCV and PPC at once in which case you can
> > keep my tag for v2 # for Arm.
>
> I previously had a patch series which made this all common, for these
> kinds of reasons.
>
> I think I'd prefer to kick that over the line, than to keep on taking
> micro-bugfixes like this.
for reference:
https://lore.kernel.org/all/20240304161041.3465897-1-andrew.cooper3@citrix.com/
I wouldn't mind that, I can R-by it if you resend it. I'll still send a
v2 of this on the grounds that it's a strict improvement over existing
matters and might land faster.
Cheers,
Alejandro
>
> ~Andrew
© 2016 - 2026 Red Hat, Inc.