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. Jan
