On 08.11.21 09:36, Jan Beulich wrote:
> On 05.11.2021 15:18, Andrew Cooper wrote:
>> On 01/11/2021 15:20, 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
>>>
>>> Juergen Gross (15):
>>> xen: limit number of hypercall parameters to 5
>>> xen: move do_vcpu_op() to arch specific code
>>> xen: harmonize return types of hypercall handlers
>>> xen/x86: modify hvm_memory_op() prototype
>>> xen: don't include asm/hypercall.h from C sources
>>> add .gitignore entries for *.[is] below xen
>>> 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
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/1752237172
>>
>> Something here causes
>>
>> hypercall.c: In function 'hvm_hypercall':
>> hypercall.c:174:23: error: unused variable 'r8' [-Werror=unused-variable]
>> 174 | unsigned long r8 = regs->r8;
>> | ^~
>> hypercall.c:190:22: error: unused variable 'edi' [-Werror=unused-variable]
>> 190 | unsigned int edi = regs->edi;
>> | ^~~
>> cc1: all warnings being treated as errors
>>
>> I suspect it will be "call hypercall handlers via generated macro", but
>> I haven't investigated further.
>
> I suspect that's a randconfig build with !HYPFS + !ARGO. The hypfs and
> argo hypercalls are the only ones with 5 parameters that HVM wires up.
> A similar issue ought to exist in PV hypercall handling though, as the
> compat form of update_va_mapping_otherdomain is the only other one
> taking 5 arguments.
>
> As to possible solutions - besides maybe adding (void)r8 to the -ENOSYS
> path, I was wondering anyway in how far the local variables are still
> warranted to retain.
I think dropping those local variables is the easiest solution. And I
think this applies to the PV variant, too.
Juergen