Re: [PATCH 03/11] arm64: gunyah: Add Gunyah hypercalls ABI

[Elliot Berman]

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@xxxxxxx> 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.