[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd8c702b-f433-0526-6945-3339a8de2f0a@quicinc.com>
Date: Wed, 13 Apr 2022 10:09:57 -0700
From: Elliot Berman <quic_eberman@...cinc.com>
To: Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>
CC: Bjorn Andersson <bjorn.andersson@...aro.org>,
<linux-kernel@...r.kernel.org>,
Trilok Soni <quic_tsoni@...cinc.com>,
"Carl van Schaik" <quic_cvanscha@...cinc.com>,
Andy Gross <agross@...nel.org>,
<linux-arm-msm@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Sudeep Holla <sudeep.holla@....com>,
Murali Nalajala <quic_mnalajal@...cinc.com>,
"Srivatsa Vaddagiri" <quic_svaddagi@...cinc.com>
Subject: Re: [PATCH 03/11] arm64: gunyah: Add Gunyah hypercalls ABI
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@....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.
>
Powered by blists - more mailing lists