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.coop...@citrix.com> >> Signed-off-by: Jan Beulich <jbeul...@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. ... this renaming, which I've done already, may have been in vein. Jan
