Re: [EXTERNAL] Re: [PATCH v5 2/6] firmware: smccc: Detect hypervisor via RSI host call in CCA Realms

[Catalin Marinas <catalin.marinas@arm.com>]

Hi Dexuan,

On Sat, Oct 31, 2026 at 04:47:32AM +0000, Dexuan Cui wrote:
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > Sent: Thursday, October 29, 2026 3:54 PM
> > > +#ifdef CONFIG_ARM64
> > > +	if (is_realm_world())
> > > +		arm_smccc_realm_get_hypervisor_uuid(&res);
> > > +	else
> > > +#endif
> > > + 	arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID,
> > > +				     &res);
> > 
> > Is this meant to be generic? I'm not sure the trick to pass
> > ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID in gprs[0] and forward it to
> > the host is a documented ABI. I think it even confuses other realm guests
> > that don't expect this (e.g. kvm_init_hyp_services()).
> 
> Regarding the concern about passing ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID
> In gprs and forwarding it to the host via an RSI Host Call: if I read the code correctly,
> this pattern actually aligns seamlessly with the current KVM host-side
> implementation for ARM CCA (e.g., in the v16 patchset [1]).

[...]

> Because KVM deliberately unpacks the RSI Host Call structure and pushes
> it down the traditional non-CVM HVC servicing pipeline, the guest passing
> standard SMCCC Function IDs inside the gprs array of an RSI Host Call is
> exactly how the host expects to handle hypervisor services. It shouldn't
> break or confuse other standard realm implementations since this exact
> emulation block translates the RSI exception back into a generic HVC
> abstraction for the hypervisor layer.

My point is not the RSI host call itself to query the UUID but what the
Realm does afterwards. kvm_init_hyp_services() gets a positive answer
for the KVM UUID and continues with an SMCCC 1.1 invocation to query the
supported KVM features. The latter is not an RSI host call but an
ordinary SMC call, to which the RMM responds with -1 in res.a0 (all
lower 32 bits set). So we end up treating KVM hyp services as available
in a Realm but their calls still use the SMC conduit and are rejected by
the RMM.

Supporting such hyp services (e.g. KVM PTP) in a Realm would need a
separate hypervisor-service conduit using RSI_HOST_CALL. Both discovery
and subsequent calls would use the same transport without adding
Realm-specific checks to each caller. Not sure how feasible this is.

-- 
Catalin