Re: [Xen-devel] [PATCH v6.5 13/26] x86/amd: Try to set lfence as being Dispatch Serialising

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.18 at 20:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/01/18 09:32, Jan Beulich wrote:
>>>>> On 04.01.18 at 01:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -558,8 +558,41 @@ static void init_amd(struct cpuinfo_x86 *c)
>>>                     wrmsr_amd_safe(0xc001100d, l, h & ~1);
>>>     }
>>>  
>>> +   /*
>>> +    * Attempt to set lfence to be Dispatch Serialising.  This MSR almost
>>> +    * certainly isn't virtualised (and Xen at least will leak the real
>>> +    * value in but silently discard writes), as well as being per-core
>>> +    * rather than per-thread, so do a full safe read/write/readback cycle
>>> +    * in the worst case.
>>> +    */
>>> +   if (c->x86 == 0x0f || c->x86 == 0x11)
>>> +           /* Always dispatch serialising on this hardare. */
>>> +           __set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
>>> +   else if (c->x86 == 0x10 || c->x86 >= 0x12) {
>> I think this could be just "else", as models below 0xf aren't 64-bit
>> capable. Anyway
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> For completeness I'm also reproducing an earlier remark I made:
>> A question though is whether it is a good idea to set the MSR
>> bit unconditionally. For example, with "bti=" being given other
>> than "lfence", it seems quite pointless to impact guest (and
>> in particular user mode) code by making LFENCE dispatch
>> serializing. Otoh a valid question is whether LFENCE is being
>> used much for purposes other than the one here.
> 
> I suppose it might be interesting for perf testing, but I can't think of
> any reasonable command line for tweaking this.
> 
> uarch=no-lfence-dispatch ?
> 
> This is the best I can think of, but its not exactly great.

I was actually meaning the MSR change to be tied to
existing options/decisions. But let's keep this for later.

Jan


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