Re: [Xen-devel] [PATCH v2 5/6] x86: (command line option to) avoid use of secondary hyper-threads

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jul 18, 2018 at 02:24:14AM -0600, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Don't use hyperthreads in such
> cases, but allow independent control of their use at the same time.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Rename option to "smt".
> ---
> An option to avoid the up/down cycle would be to avoid clearing the
> sibling (and then perhaps also core) map of parked CPUs, allowing to
> bail early from cpu_up_helper().
> 
> TBD: How to prevent the CPU from transiently becoming available for
>      scheduling when being onlined at runtime?
> 
> TBD: For now the patch assumes all HT-enabled CPUs are affected by side
>      channel attacks through shared resources. There are claims that AMD
>      ones aren't, but it hasn't really become clear to me why that would
>      be, as I don't see the fully associative L1 TLBs to be sufficient
>      reason for there to not be other possible avenues (L2 TLB, caches).
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1764,6 +1764,13 @@ Use `smap=hvm` to allow SMAP use by HVM
>  Flag to enable Supervisor Mode Execution Protection
>  Use `smep=hvm` to allow SMEP use by HVM guests only.
>  
> +### smt (x86)
> +> `= <boolean>`
> +
> +Default: `false`
> +
> +Control bring up of multiple hyper-threads per CPU core.
> +
>  ### snb\_igd\_quirk
>  > `= <boolean> | cap | <integer>`
>  
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -62,6 +62,9 @@ boolean_param("nosmp", opt_nosmp);
>  static unsigned int __initdata max_cpus;
>  integer_param("maxcpus", max_cpus);
>  
> +int8_t __read_mostly opt_smt = -1;
> +boolean_param("ht", opt_smt);
> +

But here it is still "ht"?

Wei.

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