[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250605145914.GW39944@noisy.programming.kicks-ass.net>
Date: Thu, 5 Jun 2025 16:59:14 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Kai Huang <kai.huang@...el.com>, tglx@...utronix.de, bp@...en8.de,
mingo@...hat.com, hpa@...or.com, kirill.shutemov@...ux.intel.com,
rick.p.edgecombe@...el.com, x86@...nel.org, samitolvanen@...gle.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/virt/tdx: Add ENDBR for low level SEAMCALL assembly
functions
On Thu, Jun 05, 2025 at 07:54:48AM -0700, Dave Hansen wrote:
> On 6/5/25 07:21, Peter Zijlstra wrote:
> > -static inline u64 sc_retry(sc_func_t func, u64 fn,
> > - struct tdx_module_args *args)
> > +static __always_inline u64 sc_retry(const sc_func_t func, u64 fn,
> > + struct tdx_module_args *args)
> > {
> > int retry = RDRAND_RETRY_LOOPS;
>
> Practically, I can see how this works. If the compiler doesn't inline
> sc_retry(), it stops being able to guarantee that the function pointer
> value is known.
>
> My only worry is that the compiler decides to be stupid for some other
> reason, it could start generating indirect calls again.
>
> Are we confident that __always_inline will keep the compiler from
> generating indirect calls?
Fairly sure. I've used this elsewhere too.
Also, if it ever decides to be that stupid, I'm going to log a bug and
call it broken.
Powered by blists - more mailing lists