| Message ID | 20220223233729.1571114-1-quic_eberman@quicinc.com |
|---|---|
| Headers | show |
| Series | Gunyah Hypervisor drivers | expand |
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. >