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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.01.2023 21:43, Andrew Cooper wrote:
> 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.

Hmm, so far I was understanding that the context switch operation is
solely for guests' purposes; this looks to be supported by the comments
there. If we were worried about Xen itself here (which of course is a
valid concern), then I think that together with the issue you've
spotted in patch 3 all I can do is drop the two middle patches (and
the HVM part of patch 1). At which point ...

>>  Merely mark the CPU as needing a barrier issued the
>> next time we're exiting to guest context.
>>
>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> 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.

... this renaming, which I've done already, may have been in vein.

Jan