Re: [PATCH v3 2/4] x86/spec-ctrl: defer context-switch IBPB until guest entry

[Andrew Cooper <amc96@srcf.net>]

On 25/01/2023 3:26 pm, Jan Beulich wrote:
> In order to avoid clobbering Xen's own predictions, defer the barrier as
> much as possible.

I can't actually think of a case where this matters.  We've done a
reasonable amount of work to get rid of indirect branches, and rets were
already immaterial because of the reset_stack_and_jump().

What I'm trying to figure out is whether this ends up hurting us.  If
there was an indirect call we used reliably pre and post context switch,
that changed target based on the guest type, then we'd now retain and
use the bad prediction.

>  Merely mark the CPU as needing a barrier issued the
> next time we're exiting to guest context.
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I couldn't find any sensible (central/unique) place where to move the
> comment which is being deleted alongside spec_ctrl_new_guest_context().

Given this, I'm wondering whether in patch 1, it might be better to name
the new bit SCF_new_guest_context.  Or new_pred_context context (which
on consideration, I think is better than the current name)?

This would have a knock-on effect on the feature names, which I think is
important because I think you've got a subtle bug in patch 3.

The comment really wants to stay, and it could simply move into
spec_ctrl_asm.h at that point.

~Andrew