On Tue, Sep 13, 2022 at 06:05:30PM +0200, Jan Beulich wrote: > On 13.09.2022 17:41, Roger Pau Monné wrote: > > On Tue, Jul 19, 2022 at 02:55:17PM +0200, 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. > >> > >> To allow to recover performance, introduce a new VM assist allowing the > >> guest > >> kernel to suppress this barrier. > >> > >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > >> --- > >> v2: Leverage entry-IBPB. Add VM assist. Re-base. > >> --- > >> I'm not entirely happy with re-using opt_ibpb_ctxt_switch here (it's a > >> mode switch after all, but v1 used opt_ibpb here), but it also didn't > >> seem very reasonable to introduce yet another command line option. The > >> only feasible alternative I would see is to check the CPUID bits directly. > > > > Likely needs a mention in xen-command-line.md that the `ibpb` option > > also controls whether a barrier is executed by Xen in PV vCPU context > > switches from user-space to kernel. The current text only mentions > > vCPU context switches. > > Andrew and I actually discussed this perhaps better having a separate > control.
OK, didn't know there was some feedback here already. A separate control would indeed be clearer. I guess a new patch will appear then? Thanks, Roger.
