On 09.12.2021 10:10, Juergen Gross wrote: > On 09.12.21 10:05, Jan Beulich wrote: >> On 08.12.2021 16:55, Juergen Gross wrote: >>> In order to avoid indirect function calls on the hypercall path as >>> much as possible this series is removing the hypercall function tables >>> and is replacing the hypercall handler calls via the function array >>> by automatically generated call macros. >>> >>> Another by-product of generating the call macros is the automatic >>> generating of the hypercall handler prototypes from the same data base >>> which is used to generate the macros. >>> >>> This has the additional advantage of using type safe calls of the >>> handlers and to ensure related handler (e.g. PV and HVM ones) share >>> the same prototypes. >>> >>> A very brief performance test (parallel build of the Xen hypervisor >>> in a 6 vcpu guest) showed a very slim improvement (less than 1%) of >>> the performance with the patches applied. The test was performed using >>> a PV and a PVH guest. >>> >>> Changes in V2: >>> - new patches 6, 14, 15 >>> - patch 7: support hypercall priorities for faster code >>> - comments addressed >>> >>> Changes in V3: >>> - patches 1 and 4 removed as already applied >>> - comments addressed >>> >>> Juergen Gross (13): >>> xen: move do_vcpu_op() to arch specific code >>> xen: harmonize return types of hypercall handlers >>> xen: don't include asm/hypercall.h from C sources >>> xen: include compat/platform.h from hypercall.h >>> xen: generate hypercall interface related code >>> xen: use generated prototypes for hypercall handlers >>> x86/pv-shim: don't modify hypercall table >>> xen/x86: don't use hypercall table for calling compat hypercalls >>> xen/x86: call hypercall handlers via generated macro >>> xen/arm: call hypercall handlers via generated macro >>> xen/x86: add hypercall performance counters for hvm, correct pv >>> xen: drop calls_to_multicall performance counter >>> tools/xenperf: update hypercall names >> >> It's not easy to tell which, if any, of the later patches are fully >> independent of earlier ones and could go in ahead of those awaiting >> further acks. Do you have any suggestion there, or should we wait >> until things can be applied in order? > > I think all but the last patch should be applied in order. The last one > obviously can be applied at any time.
Hmm, I think 11 and 12 are fine to go ahead as well; I actually need them for some immediate purpose and hence I did pull them (but nothing else) into my local tree, without observing issues. Jan
