On 09/01/18 13:24, Jan Beulich wrote:
>>>> On 09.01.18 at 12:44, <andrew.coop...@citrix.com> wrote:
>> On 04/01/18 09:40, Jan Beulich wrote:
>>>>>> On 04.01.18 at 01:15, <andrew.coop...@citrix.com> 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?
These thunks have lower overhead that IBRS in all measurements I've
seen. ISTR retpoline was specifically put together to combat the IBRS
perf hit.
One complication is that Skylake (and Broadwell before a specific
microcode version) are not safe even with retpoline, so IBRS is used
unconditionally. (The microcode version to add IBRS to Broadwell causes
it to pass the retpoline-safety test).
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
