Re: [PATCH 0/6] xsm: refactoring xsm hooks

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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
3) Switch x86's current use over to this new interface

The iommu_vcall() is a red herring, not adequately documented, and needs
to stay in some form.  Specifically, it needs to not become an
alternative on ARM, even if ARM gains vcalls.  I'd be tempted to rework
it in 4) to use the common vcall() by default, and leave ARM as the
special case overriding the default behaviour, along with an explanation
of why it isn't a vcall().

Obviously, name subject bikeshedding.  alternative_vcall() is a bit of a
mouthful, and I don't think that alt_vcall() loses any salient information.

Thoughts?

~Andrew