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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.12.18 at 18:09, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/12/2018 16:50, Jan Beulich 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 */
>> ... here, but I still will need to see how this gets used before
>> giving my ack here. Additionally I can see "legacy" as a suitable
>> name for the LS_CFG approach, but does this also fit the
>> VIRT_SPEC_CTRL one?
> 
> In practice, VIRT_SPEC_CTRL means "your hypervisor is using LS_CFG on
> your behalf".
> 
> As to the joint meaning, that's because it is the most appropriate (i.e.
> simple) way to structure the code.

Synthetic feature bits, other than simple boolean variables, are
mainly (if not exclusively) meant to allow keying off of them
alternatives patching. For two different approaches like the
ones here this seems unlikely to be the goal, but since I didn't
make it to the end of the series yet, I didn't want to judge early.

Jan



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