[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87va35e61a.fsf@linux.intel.com>
Date: Thu, 03 Jan 2019 14:21:37 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Nadav Amit <namit@...are.com>
Cc: Ingo Molnar <mingo@...hat.com>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Edward Cree <ecree@...arflare.com>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Nadav Amit <nadav.amit@...il.com>, X86 ML <x86@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Borislav Petkov <bp@...en8.de>,
David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [RFC v2 1/6] x86: introduce kernel restartable sequence
Nadav Amit <namit@...are.com> writes:
I see another poor man's attempt to reinvent TSX.
> It is sometimes beneficial to have a restartable sequence - very few
> instructions which if they are preempted jump to a predefined point.
>
> To provide such functionality on x86-64, we use an empty REX-prefix
> (opcode 0x40) as an indication for instruction in such a sequence. Before
> calling the schedule IRQ routine, if the "magic" prefix is found, we
> call a routine to adjust the instruction pointer. It is expected that
> this opcode is not in common use.
You cannot just assume something like that. x86 is a constantly
evolving architecture. The prefix might well have meaning at
some point.
Before doing something like that you would need to ask the CPU
vendors to reserve the sequence you're using for software use.
You're doing the equivalent of patching a private system call
into your own kernel without working with upstream, don't do that.
Better to find some other solution to do the restart.
How about simply using a per cpu variable? That should be cheaper
anyways.
-Andi
Powered by blists - more mailing lists