Re: [Xen-devel] [PATCH v6.5 14/26] x86: Introduce alternative indirect thunks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.01.18 at 12:44, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/01/18 09:40, Jan Beulich wrote:
>>>>> On 04.01.18 at 01:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +    else
>>> +    {
>>> +        /*
>>> +         * Evaluate the safest Branch Target Injection mitigations to use.
>>> +         * First, begin with compiler-aided mitigations.
>>> +         */
>>> +        if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
>>> +        {
>>> +            /*
>>> +             * AMD's recommended mitigation is to set lfence as being 
>>> dispatch
>>> +             * serialising, and to use IND_THUNK_LFENCE.
>>> +             */
>>> +            if ( cpu_has_lfence_dispatch )
>>> +                thunk = THUNK_LFENCE;
>>> +        }
>>> +    }
>> As asked elsewhere, is the CONFIG_INDIRECT_THUNK dependency
>> here really meaningful for the overall effect? Surely if we can't use
>> thunks in the first place it doesn't matter which variant of them we
>> don't use?
> 
> In later patches, the lack of INDIRECT_THUNK causes us to choose to use
> IBRS+ if available in microcode.

Oh, I see, but that patch has no description so far, and hence it
is not really clear what the backgrounds of the decisions there is
(even to me, having been involved in this for some time). Is the
expected (or measured?) overhead of using the thunks lower
than that of IBRS?

Jan


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