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

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



On 13.12.21 11:35, Jan Beulich wrote:
On 09.12.2021 10:10, Juergen Gross wrote:
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.

Hmm, I think 11 and 12 are fine to go ahead as well; I actually need them
for some immediate purpose and hence I did pull them (but nothing else)
into my local tree, without observing issues.

Yeah, those should be okay to take.


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