Re: [PATCH v3 00/13] xen: drop hypercall function tables

[Juergen Gross <jgross@xxxxxxxx>]

On 09.12.21 10:05, 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
> It's not easy to tell which, if any, of the later patches are fully
> independent of earlier ones and could go in ahead of those awaiting
> further acks. Do you have any suggestion there, or should we wait
> until things can be applied in order?
I think all but the last patch should be applied in order. The last one
obviously can be applied at any time.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature