Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/03/18 13:47, Jan Beulich wrote:
> Introduce a synthetic feature flag to use alternative instruction
> patching to NOP out all code on entry/exit paths. Having NOPs here is
> generally better than using conditional branches.
>
> Also change the limit on the number of bytes we can patch in one go to
> that resulting from the encoding in struct alt_instr - there's no point
> reducing it below that limit, and without a check being in place that
> the limit isn't actually exceeded, such an artificial boundary is a
> latent risk.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Tested-by: Juergen Gross <jgross@xxxxxxxx>
> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>

I'm afraid that I still have misgivings about this patch.

While I'm quite willing to trust that it functions correctly, it is
taking a some code which is almost impossible to follow already, and
making it substantially more complicated to follow, for what appears to
be a fractional gain.

The two distinct areas of concern are the split interrupt re-enablement
(which really doesn't buy us anything useful), and how obvious the
nopping is (where in the .Lxcpt_cr3_start case, the ALTERNATIVE_NOP is
111 lines (!) away from the code it applies to).

I.e. I'm struggling to decide whether it falls into the category of
unnecessary micro-optimisation or not.

Therefore, I'd like to consider what other XPTI changes we're expecting
to get, and whether those have an impact.

I've got a patch (which I've not had time to submit upstream yet, but
would like to get in for 4.11) which implements a crude "no XPTI for
dom0" mode.  Performance testing shows that in scenarios running only
HVM guests (a very common XenServer setup), the difference between dom0
XPTI-ness can be up to 40% in terms of aggregate network/disk throughput.

OTOH, I expect my patch will likely change based on Juergen's series
(which I should probably stop using as an excuse to defer).  What other
changes are we expecting?

~Andrew

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