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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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