>>> On 12.01.18 at 19:01, <andrew.coop...@citrix.com> wrote:
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -20,8 +20,29 @@
> #ifndef __X86_SPEC_CTRL_H__
> #define __X86_SPEC_CTRL_H__
>
> +#include <xen/sched.h>
> +
> void init_speculation_mitigations(void);
>
> +/*
> + * For guests which know about IBRS but are not told about STIBP running on
> + * hardware supporting hyperthreading, the guest doesn't know to protect
> + * itself fully. (Such a guest won't be permitted direct access to the MSR.)
> + * Have Xen fill in the gaps, so an unaware guest can't be interfered with by
> + * a meddling guest on an adjacent hyperthread.
> + */
> +static inline unsigned int spec_ctrl_host_val(const struct domain *d,
> + unsigned int guest_val)
> +{
> + const struct cpuid_policy *cp = d->arch.cpuid;
> +
> + if ( !cp->feat.stibp && cpu_has_stibp &&
> + !(guest_val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
> + return SPEC_CTRL_STIBP;
> + else
> + return guest_val;
> +}
The comment's "won't be permitted direct access" can be verified
by looking at patch 10, but where's the HT dependency here (or
in another patch)? For now it looks to me as if you enabled this
behind-the-back protection even in the non-HT case.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
