From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
"Daniel P. Smith" <dpsmith@apertussolutions.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
Subject: Re: [PATCH 0/6] xsm: refactoring xsm hooks
Date: Fri, 18 Jun 2021 22:21:19 +0100 [thread overview]
Message-ID: <6ed12320-f454-2751-1a41-014eaa835762@citrix.com> (raw)
In-Reply-To: <b921c150-84f7-3ab3-1e4a-89d00725d9da@suse.com>
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
next prev parent reply other threads:[~2021-06-18 21:21 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 23:39 [PATCH 0/6] xsm: refactoring xsm hooks Daniel P. Smith
2021-06-17 23:39 ` [PATCH 1/6] xsm: refactor xsm_ops handling Daniel P. Smith
2021-06-18 11:34 ` Andrew Cooper
2021-06-18 11:44 ` Jan Beulich
2021-06-18 11:45 ` Andrew Cooper
2021-06-18 16:26 ` Daniel P. Smith
2021-06-18 16:17 ` Daniel P. Smith
2021-07-12 12:36 ` [PATCH 0.5/6] xen: Implement xen/alternative-call.h for use in common code Andrew Cooper
2021-06-17 23:39 ` [PATCH 2/6] xsm: decouple xsm header inclusion selection Daniel P. Smith
2021-06-17 23:39 ` [PATCH 3/6] xsm: enabling xsm to always be included Daniel P. Smith
2021-06-18 11:53 ` Andrew Cooper
2021-06-18 16:35 ` Daniel P. Smith
2021-06-21 6:53 ` Jan Beulich
2021-06-24 17:18 ` Daniel P. Smith
2021-06-25 6:39 ` Jan Beulich
2021-06-18 12:26 ` Jan Beulich
2021-06-18 20:27 ` Daniel P. Smith
2021-06-21 6:58 ` Jan Beulich
2021-06-21 10:41 ` Andrew Cooper
2021-06-21 11:39 ` Jan Beulich
2021-06-18 21:20 ` Andrew Cooper
2021-06-21 7:03 ` Jan Beulich
2021-06-17 23:39 ` [PATCH 4/6] xsm: remove xen_defualt_t from hook definitions Daniel P. Smith
2021-06-18 11:56 ` Andrew Cooper
2021-06-18 16:35 ` Daniel P. Smith
2021-06-18 12:32 ` Jan Beulich
2021-06-17 23:39 ` [PATCH 5/6] xsm: expanding function related macros in dummy.h Daniel P. Smith
2021-06-18 12:03 ` Andrew Cooper
2021-06-18 12:40 ` Jan Beulich
2021-06-18 12:44 ` Jan Beulich
2021-06-18 16:38 ` Daniel P. Smith
2021-06-18 16:36 ` Daniel P. Smith
2021-06-17 23:39 ` [PATCH 6/6] xsm: removing the XSM_ASSERT_ACTION macro Daniel P. Smith
2021-06-18 10:14 ` [PATCH 0/6] xsm: refactoring xsm hooks Andrew Cooper
2021-06-18 11:48 ` Jan Beulich
2021-06-18 21:21 ` Andrew Cooper [this message]
2021-06-21 6:45 ` Jan Beulich
2021-06-18 15:53 ` Daniel P. Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ed12320-f454-2751-1a41-014eaa835762@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=adam.schwalm@starlab.io \
--cc=aisaila@bitdefender.com \
--cc=christopher.w.clark@gmail.com \
--cc=dfaggioli@suse.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=dpsmith@apertussolutions.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=persaur@gmail.com \
--cc=ppircalabu@bitdefender.com \
--cc=roger.pau@citrix.com \
--cc=scott.davis@starlab.io \
--cc=sstabellini@kernel.org \
--cc=tamas@tklengyel.com \
--cc=tim@xen.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).