[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <5A5AF726-1D7C-4267-90D8-7E6BD464BA47@amacapital.net>
Date: Mon, 6 Apr 2020 18:53:10 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Cc: Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Ricardo Neri <ricardo.neri@...el.com>, X86 ML <x86@...nel.org>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>
Subject: Re: [PATCH] x86/cpufeatures: Add enumeration for serialize instruction
> On Apr 6, 2020, at 6:37 PM, Ricardo Neri <ricardo.neri-calderon@...ux.intel.com> wrote:
>
> On Sat, Apr 04, 2020 at 02:15:57PM -0700, Andy Lutomirski wrote:
>>> On Fri, Apr 3, 2020 at 10:19 PM Ricardo Neri
>>> <ricardo.neri-calderon@...ux.intel.com> wrote:
>>>
>>> On Fri, Apr 03, 2020 at 10:12:17AM +0200, Borislav Petkov wrote:
>>>> On Thu, Apr 02, 2020 at 06:40:26PM -0700, Ricardo Neri wrote:
>>>>> The serialize instruction ensures that before the next instruction is
>>>>> fetched and executed, all the modifications to flags, registers, and memory
>>>>> made by previous instructions are completed, draining all buffered writes
>>>>> to memory.
>>>>>
>>>>> Importantly, the serialize instruction does not modify registers,
>>>>> arithmetic flags or memory.
>>>>>
>>>>> Hence, the serialize instructions provides a better way for software
>>>>> to serialize execution than using instructions such as cpuid, which does
>>>>> modify registers and, in virtual machines, causes a VM exit.
>>>>>
>>>>> This instruction is supported by the CPU if CPUID.7H.EDX[bit 14] is
>>>>> set.
>>>>>
>>>>> Cc: x86@...nel.org
>>>>> Cc: "Ravi V. Shankar" <ravi.v.shankar@...el.com>
>>>>> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
>>>>> ---
>>>>> This new instruction is documented in the latest version of the Intel
>>>>> Architecture Instruction Set Extensions and Future Features Programming
>>>>> Reference Chapter 2.1 located at
>>>>> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>>>>> ---
>>>>> arch/x86/include/asm/cpufeatures.h | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
>>>>> index db189945e9b0..cd9b1ec022ec 100644
>>>>> --- a/arch/x86/include/asm/cpufeatures.h
>>>>> +++ b/arch/x86/include/asm/cpufeatures.h
>>>>> @@ -364,6 +364,7 @@
>>>>> #define X86_FEATURE_AVX512_VP2INTERSECT (18*32+ 8) /* AVX-512 Intersect for D/Q */
>>>>> #define X86_FEATURE_MD_CLEAR (18*32+10) /* VERW clears CPU buffers */
>>>>> #define X86_FEATURE_TSX_FORCE_ABORT (18*32+13) /* "" TSX_FORCE_ABORT */
>>>>> +#define X86_FEATURE_SERIALIZE (18*32+14) /* SERIALIZE instruction */
>>>>> #define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */
>>>>> #define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control (IBRS + IBPB) */
>>>>> #define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread Indirect Branch Predictors */
>>>>> --
>>>>
>>>> Send this together with code which is using it, pls.
>>>
>>> Do you mean code in the kernel using this instructions. Thus far, I
>>> don't have any kernel use cases for this instruction. My intention is to expose
>>> this instruction to user space via /proc/cpuinfo. Is that not
>>> acceptable?
>>
>> Presumably sync_core() should do, roughly:
>>
>> if (static_cpu_has(X86_FEATURE_SERIALIZE)) {
>> asm volatile("serialize");
>> return;
>> }
>
> Sure Andy, I will look at implementing something as you propose.
>
>>
>> but with the appropriate magic to build it on older binutils.
>
> But old binutils will not be aware of this new instruction, right? How
> could they be impacted?
Because old binutils will fail to assemble serialize :). You’re need a macro that turns it into .byte, or, if there’s just one user, you could open-code the .byte.
>
>> should make sure that the in-kernel instruction decoder doesn't
>> explode when it sees serialize, presumably.
>
> Sure Andy. I will also test for this.
>
> Thanks and BR,
> Ricardo
Powered by blists - more mailing lists