Re: [PATCH 2/2] x86/cpuid: support LFENCE always serializing CPUID bit

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/04/2021 13:45, Jan Beulich wrote:
> On 14.04.2021 14:33, Andrew Cooper wrote:
>> On 14/04/2021 12:04, Roger Pau Monne wrote:
>>> --- a/tools/misc/xen-cpuid.c
>>> +++ b/tools/misc/xen-cpuid.c
>>> @@ -178,6 +178,11 @@ static const char *const str_7a1[32] =
>>>      [ 4] = "avx-vnni",      [ 5] = "avx512-bf16",
>>>  };
>>>  
>>> +static const char *const str_e21a[32] =
>>> +{
>>> +    [ 2] = "lfence-always-serializing",
>> This is a bit of a mouthful.  One problem is the fact that "serialising"
>> is an ambiguous term, because neither Intel nor AMD formally specify
>> what it means in the architecture.
>>
>> There is a description of what "architecturally serialising" does, which
>> does occasionally move over time, and the name of this CPUID bit in the
>> PPR confusing at best, because it very much isn't "architecturally
>> serialising", and the term "dispatch serialising" isn't actually defined
>> anywhere.
>>
>> Intel have now started referring to LFENCE as a "speculative execution
>> barrier", but this still doesn't have a precise definition.
>>
>> I'm afraid I don't have a useful suggestion for something short and
>> concise, which also conveys the precise meaning.
> How about "lfence+" or some such?

Hmm yes - for xen-cpuid, that's probably fine, and for churn reasons, we
can keep X86_FEATURE_LFENCE_DISPATCH which was the best name I could
come up with at the time.

~Andrew