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

[Marc Zyngier]

Thanks Mark for roping me in.

On Thu, 24 Feb 2022 10:10:02 +0000,
Mark Rutland <mark.rutland at 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.

> 
> 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?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.