On 08.03.2022 09:39, Juergen Gross wrote: > On 08.03.22 09:34, 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 >> >> As it's pretty certain now that parts of this which didn't go in yet will >> need re-basing, I'm going to drop this from my waiting-to-be-acked folder, >> expecting a v4 instead. > > Yes, I was planning to spin that up soon. > > The main remaining question is whether we want to switch the return type > of all hypercalls (or at least the ones common to all archs) not > requiring to return 64-bit values to "int", as Julien requested.
Could you remind me of the (sub)thread this was in, to read through the justification again? Without recalling any details I guess I'd prefer to stick to long for non-compat flavors. Jan
