* Peter Zijlstra wrote:
> Nope, they do as they say on the tin.
>
> noinstr void foo(void)
> {
> }
>
> declares the whole function as non-instrumented.
>
> Within such functions, we demark regions where instrumentation is
> allowed by:
>
> noinstr void foo(void)
> {
> instrumentation_
On Tue, Jan 17, 2023 at 10:31:05AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > + /*
> > +* Definitely wrong, but at this point we should have at least enough
> > +* to do CALL/RET (consider SKL callthunks) and this avoids having
> > +* to deal with the noinstr explo
* Peter Zijlstra wrote:
> + /*
> + * Definitely wrong, but at this point we should have at least enough
> + * to do CALL/RET (consider SKL callthunks) and this avoids having
> + * to deal with the noinstr explosion for now :/
> + */
> + instrumentation_begin();
BTW.
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.
