Re: [Xen-devel] [PATCH 5/9] x86/amd: Probe for legacy SSBD interfaces on boot

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.12.18 at 17:30, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/12/2018 10:59, Jan Beulich wrote:
>>>>> On 03.12.18 at 17:18, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/include/asm-x86/cpufeatures.h
>>> +++ b/xen/include/asm-x86/cpufeatures.h
>>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,        (FSCAPINTS+0)*32+11) /* 
> SMAP gets used by Xen it
>>>  XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as 
> Dispatch Serialising */
>>>  XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use 
> IND_THUNK_LFENCE */
>>>  XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP 
> */
>>> +XEN_CPUFEATURE(LEGACY_SSBD,     (FSCAPINTS+0)*32+15) /* LS_CFG or 
> VIRT_SPEC_CTRL available for SSBD */
>> As already indicated in another reply, with there not being
>> any alternatives patching based on this, I don't think it should
>> be a synthetic feature. Use an ordinary bool variable instead.
> 
> What makes you believe that synthetic bits are only for livepatching? 
> Less than half of the existing ones are used for that purpose, and its
> not how Linux treats them.
> 
> They are a collection of misc unsorted feature bits, and that's exactly
> what I'm using it for here.

I'm convinced the introduction of synthetic bits in Linux was
for the purpose of alternatives patching, as anything else can
be expressed using ordinary variables. Even if Linux later went
and abused the construct, I don't think we should follow that
model; I'd actually aim at removing synthetic features which
aren't used for alternatives patching, as you can see from e.g.
56e619b4d3 ("x86: drop NO_XPTI synthetic feature").

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel