lkml.org 
[lkml]   [2022]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 03/11] arm64: gunyah: Add Gunyah hypercalls ABI
From


On 2/24/2022 2:26 AM, Marc Zyngier wrote:
> Thanks Mark for roping me in.
>
> On Thu, 24 Feb 2022 10:10:02 +0000,
> Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> Hi,
>>
>> As a general thing, this is the *only* patch from this series which has
>> been Cc'd to linux-arm-kernel, which makes it practically impossible to
>> understand the context for this, which is somewhat frustrating.
>>
>> Looking on lore.kernel.org I see that the entire series was Cc'd to
>> linux-arm-msm, but most people don't subscribe to that list. If you send
>> one patch in a series to a list, please send the *entire* series there. >>>> On Wed, Feb 23, 2022 at 03:37:21PM -0800, Elliot Berman wrote:
>>> Add initial support to perform Gunyah hypercalls. The arm64 ABI for
>>> Gunyah hypercalls generally follows the AAPCS64, and can be summarized:
>>> - Function identifier is passed through the imm operand
>>> - [r0,r7] are parameter and result registers
>>> - [r8-r18] are temporary and saved by the caller (VM)
>>> - [r19-r31] are preserved and saved by the hypervisor
>>>
>>> The preprocessor macors for creating the necessary HVC instruction
>>> roughly follows the SMCCC 1.1 implementation in
>>> include/linux/arm-smccc.h.
>>
>> I've added the SMCCC maintainers (myself, Lorenzo, and SUdeep) to Cc,
>> and also Marc who was involvedi n prior discussions in this area. Please
>> Cc us on any future patches adding HVC or SMCC interfaces (SMCCC or
>> otherwise).
>
> In general, please Cc all the interested parties with the whole
> series. Random patches randomly cc'd out of context are pretty useless
> and only lead to them being ignored.
>

I'll do this in the future, thanks for the recommendation here.

>>
>> We've previously said NO to any new hypercall mechanisms which do not
>> follow SMCCC. There is no reason to fragment this space further; please
>> use SMCCC (which your hypervisor must already implement in part if it
>> exposes PSCI to a guest).
>>
>> NAK to this non-SMCCC interface.
>
> Agreed. We pushed back on that for Hyper-V, and I don't see a reason
> for changing tack on that.
>
> The calling convention exists for a reason: portability. If this
> hypervisor is to be "independent of any high-level OS kernel" (as it
> is being advertised), then it must already implement SMCCC.
>
> What is the issue with properly supporting SMCCC for all interactions
> with the hypervisor and not reinventing a square wheel? >

We had discussion on this and will implement SMCCC calls for Gunyah's
hypercalls. I'll share updated patches soon once we have update the
hypervisor.

> Thanks,
>
> M.
>

\
 
 \ /
  Last update: 2022-04-13 19:11    [W:1.288 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site