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.


Juergen