[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 00/15] xen: drop hypercall function tables



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

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.