[PATCH v5 00/13] x86: indirect call overhead reduction

["Jan Beulich" <JBeulich@suse.com>]

While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.

Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are vPMU and XSM. For the latter, the Arm side would need dealing
with as well - I'm not sure whether replacing indirect calls by direct ones
is worthwhile there; if not, the wrappers would simply need to become
function invocations in the Arm case (as is already done in the IOMMU
case).

01: x86: reduce general stack alignment to 8
02: x86: clone Linux'es ASM_CALL_CONSTRAINT
03: x86: infrastructure to allow converting certain indirect calls to direct ones
04: x86/HVM: patch indirect calls through hvm_funcs to direct ones
05: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
06: x86: patch ctxt_switch_masking() indirect call to direct one
07: x86/genapic: patch indirect calls to direct ones
08: x86/cpuidle: patch some indirect calls to direct ones
09: cpufreq: convert to a single post-init driver (hooks) instance
10: cpufreq: patch target() indirect call to direct one
11: IOMMU: move inclusion point of asm/iommu.h
12: IOMMU: remove indirection from certain IOMMU hook accesses
13: IOMMU: patch certain indirect calls to direct ones

Patches 1 and 2 are new in v5, addressing v4 remarks on what is now
patch 3. The IOMMU patches required quite some re-work, and patch
11 is also new (the former patch at that place in the series as dropped
as requested).

Jan





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