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

From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Ian Jackson" <iwj@xenproject.org>, "Wei Liu" <wl@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Tamas K Lengyel" <tamas@tklengyel.com>,
	"Tim Deegan" <tim@xen.org>, "Juergen Gross" <jgross@suse.com>,
	"Alexandru Isaila" <aisaila@bitdefender.com>,
	"Petre Pircalabu" <ppircalabu@bitdefender.com>,
	"Dario Faggioli" <dfaggioli@suse.com>,
	"Paul Durrant" <paul@xen.org>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
	persaur@gmail.com, christopher.w.clark@gmail.com,
	adam.schwalm@starlab.io, scott.davis@starlab.io,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: Re: [PATCH 0/6] xsm: refactoring xsm hooks
Date: Mon, 21 Jun 2021 08:45:57 +0200	[thread overview]
Message-ID: <529179db-ea47-72a8-ed71-604b1da2b4cd@suse.com> (raw)
In-Reply-To: <6ed12320-f454-2751-1a41-014eaa835762@citrix.com>

On 18.06.2021 23:21, Andrew Cooper wrote:
> 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.

Which iirc wasn't there yet when I wrote ours.

> Would a general alt_call name be acceptable?

Well, it seemed a little terse to me at the time, but I'm not opposed.
There's hardly anything else the "alt" there could stand for, I guess.

Jan