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

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


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 18 Jun 2021 11:14:55 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oYijSs5H+YfN+SKleG5HxJrXs5ojrMbCfsis7erSI4E=; b=bFQx8985cwZjghIc+VMN3ic197YHAvIvML7cCC/XxEtOfsGmXo0veatXwbaN1TXwLEU3LahSDrIQiFVC1FKQC2B0aSLn7O+xH7Adrm6ri8uUYVMxq+Sp38OHxEMlnD+N9zPPgdjxUr4PL4/zC4ed+jY5K/xMe8iwGTO8vUL1nZkVhdsjfE8EcSOVkyIIJKNE8GSKXYpT8puyXEx2GPQYrZPsZdXzFfr3SLHxZ7dEw8BTCS40WU461IgSFDIYF2mVMji/2+mHkoV+PPM5ZJsSFPSHaXHKOwraoOve0JCAtloFG6fzBly3X/I8EZDsMDazUW51xlGUT/pWg/y3MxwsYg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CK3GdFSHc4MuvaisFwOSmzB//A6sl29Onspib2ZmdnuTynXHBLtOwDVM0gWNSIqqpUKPVZREjxdsg+SLhv+PBO6+A3zefvM21ujjs5L67FkNazxTDNdTgB3zFXQ5ZX+e+LrGouOfzwsYfL57+74vyjoNeDZ0gHqsxneIlt1qfcUH6ibuyFRBs8tCaVZWSCSM5IZ46Rd/HeoNy/OsJHC4abxKFID956menF3RrHdkQ7cVCq4Tg9Jqwzjj7u4xvV7NZwUkUNNr2TQ0yLyzXNy65RYPifcPARAPzAp53vBVgeSf8iJSZFJ/udSoRiNZMfDDy+5QZDfrw+yeC6AqN0gYHg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "George Dunlap" <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, "Petre Pircalabu" <ppircalabu@xxxxxxxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, <persaur@xxxxxxxxx>, <christopher.w.clark@xxxxxxxxx>, <adam.schwalm@xxxxxxxxxx>, <scott.davis@xxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 10:15:22 +0000
  • Ironport-hdrordr: A9a23:/qy77qiQHHwQWxPybOL9JTX/rHBQXiAji2hC6mlwRA09TyX5ra 2TdTogtSMc6QxhPE3I/OrrBEDuexzhHPJOj7X5Xo3SOTUO2lHYT72KhLGKq1Hd8kXFndK1vp 0QEZSWZueQMbB75/yKnTVREbwbsaW6GHbDv5ag859vJzsaFZ2J921Ce2Gm+tUdfng8OXI+fq DsgPZvln6bVlk8SN+0PXUBV/irnaywqHq3CSR2fiLO8WO1/EuV1II=
  • Ironport-sdr: a0Olj0259qjlTRGaNER4aKtFQDzF5+/YvaOa6UEhpCCGPDASdnkMX8d1wdjno28JbO6uA+6NFu PDXpu8j8XMqZju4eZfl72+SzTPegD+N9ZWeBZssVjH0WHvGfNEi+n2m95Wrb9FZdbbLgCyn+g8 1lHMsDpawkEZkWC1u9TR5pTwxBh/dthkXb7JC8kY/3oaDJeZoOZdY8k6P/r18mNfi/ZOFiZVEb zvyGQUOXGrt32V2sd7EdVn/d8zOIuCds55x4d72I7sn0+plaNC4uqGdhm+10ZKuiMBNMhSPQqK 7MU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.