On 23/01/2019 11:57, Norbert Manthey wrote:
> While the lfence instruction was added for all x86 platform in the
> beginning, it's useful to not block platforms that are not affected
> by the L1TF vulnerability. Therefore, the lfence instruction should
> only be introduced, in case the current CPU is an Intel CPU that is
> capable of hyper threading. This combination of features is added
> to the features that activate the alternative.
>
> This commit is part of the SpectreV1+L1TF mitigation patch series.
>
> Signed-off-by: Norbert Manthey <nmant...@amazon.de>
>
> ---
> xen/include/xen/nospec.h | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h
> --- a/xen/include/xen/nospec.h
> +++ b/xen/include/xen/nospec.h
> @@ -7,6 +7,7 @@
> #ifndef XEN_NOSPEC_H
> #define XEN_NOSPEC_H
>
> +#include <asm/alternative.h>
> #include <asm/system.h>
>
> /**
> @@ -68,7 +69,10 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> * allow to insert a read memory barrier into conditionals
> */
> #ifdef CONFIG_X86
> -static inline bool lfence_true(void) { rmb(); return true; }
> +static inline bool lfence_true(void) {
> + alternative("", "lfence", X86_VENDOR_INTEL);
This doesn't do what you expect. It will cause the lfences to be
patched into existence on any hardware with an FPU (before a recent
patch of mine) or with VME (after a recent patch).
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
