Re: [Xen-devel] [PATCH] x86: issue branch prediction barrier when switching 64-bit guest to kernel mode

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/02/18 15:39, Jan Beulich wrote:
> Since both kernel and user mode run in ring 3, they run in the same
> "predictor mode". While the kernel could take care of this itself, doing
> so would be yet another item distinguishing PV from native. Additionally
> we're in a much better position to issue the barrier command, and we can
> save a #GP (for privileged instruction emulation) this way.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

(In microcode at least) IBPB is crippling in terms of performance hit,
and a retpolined kernel doesn't need the BTB to be flushed on entry.

An opt-in VMASSIST might be useful for PV guests running on Skylake+
hardware, but we certainly shouldn't issue the barrier blindly.

Alternatively/additionally, a hypercall_iret flag indicating "I'm return
to a new logical context" would probably also be useful, to avoid a
trap&emulate in the context switch path.

~Andrew

>
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -10,6 +10,7 @@
>  #include <xen/sched.h>
>  
>  #include <asm/pv/domain.h>
> +#include <asm/spec_ctrl.h>
>  
>  /* Override macros from asm/page.h to make them work with mfn_t */
>  #undef mfn_to_page
> @@ -251,6 +252,10 @@ void toggle_guest_mode(struct vcpu *v)
>          else
>              v->arch.pv_vcpu.gs_base_user = __rdgsbase();
>      }
> +
> +    if ( opt_ibpb && !(v->arch.flags & TF_kernel_mode) )
> +        wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
> +
>      asm volatile ( "swapgs" );
>  
>      _toggle_guest_pt(v);
>
>
>


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