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.
From patch 2 onwards dependencies exist on earlier, yet to be reviewed patches ("x86/alternatives: fully leverage automatic NOP filling" as well as the "x86: improve PDX <-> PFN and alike translations" series at the very least). I nevertheless wanted to enable a first round of review of the series, the more that some of the patches (not just initial ones) could perhaps be taken irrespective of those dependencies. The first two of the three genapic patches, otoh, are entirely independent and could go in right away afaict if they were ack-ed. 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 IOMMU, vPMU, and XSM. For some of these, the ARM side would need dealing with as well - I'm not sure whether replacing indirect calls by direct ones is worthwhile there as well; if not, the wrappers would simply need to become function invocations in the ARM case (as was already asked for in the IOMMU case). 1: x86: infrastructure to allow converting certain indirect calls to direct ones 2: x86/HVM: patch indirect calls through hvm_funcs to direct ones 3: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones 4: x86: patch ctxt_switch_masking() indirect call to direct one 5: x86/genapic: remove indirection from genapic hook accesses 6: x86/genapic: patch indirect calls to direct ones 7: x86/cpuidle: patch some indirect calls to direct ones 8: cpufreq: convert to a single post-init driver (hooks) instance 9: cpufreq: patch target() indirect call to direct one Besides some re-basing only patch 1 has really changed from v2. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel