On 18/06/2021 12:48, Jan Beulich wrote: > On 18.06.2021 12:14, Andrew Cooper wrote: >> On 18/06/2021 00:39, Daniel P. Smith wrote: >>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC >>> patch set is being split into two separate patch sets. This is the first >>> patch set and is focused purely on the clean up and refactoring of the >>> XSM hooks. >>> >>> This patch set refactors the xsm_ops wrapper hooks to use the >>> alternative_call >>> infrastructure. Then proceeds to move and realign the headers to remove the >>> psuedo is/is not enable implementation. The remainder of the changes are >>> clean up >>> and removing no longer necessary abstractions. >>> >>> <snip> >>> 51 files changed, 1309 insertions(+), 1413 deletions(-) >> The diffstat is great, but sadly CI says no. >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/323044913 >> >> The problem is that ARM doesn't have alternative_vcall(). Given how >> much of an improvement this ought to be for hypercalls, I don't want to >> lose the vcalls. >> >> One option is to implement vcall() support on ARM, but that will leave >> new architectures (RISC-V on the way) with a heavy lift to get XSM to >> compile. >> >> Instead, what we want to do is make vcall() a common interface, falling >> back to a plain function pointer call for architectures which don't >> implement the optimisation. So something like: >> >> 1) Introduce CONFIG_HAS_VCALL, which is selected by X86 only right now >> 2) Introduce xen/vcall.h which uses CONFIG_HAS_VCALL to either include >> asm/vcall.h or provide the fallback implementation > A word on the suggested names: The 'v' in alternative_vcall() stands for > "returning void", as opposed to alternative_call(). It's unclear to me > what you see it stand for in the names you propose.
Urgh - yet another reason to prefer the Linux static_call() infrastructure. Would a general alt_call name be acceptable? ~Andrew
