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

[Suzuki K Poulose]

Hi

On 31/10/2026 04:47, Dexuan Cui wrote:
> > From: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Sent: Thursday, October 29, 2026 3:54 PM
> >   ...
> > + Suzuki
> >   ...
> > > +static void arm_smccc_realm_get_hypervisor_uuid(struct arm_smccc_res
> > *res)
> > > +{
> > > +	guard(spinlock_irqsave)(&uuid_hc_lock);
> > > +
> > > +	memset(&uuid_hc, 0, sizeof(uuid_hc));
> > > +	uuid_hc.gprs[0] = ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID;
> > > +
> > > +	if (rsi_host_call(__pa_symbol(&uuid_hc)) != RSI_SUCCESS) {
> > > +		res->a0 = SMCCC_RET_NOT_SUPPORTED;
> > > +		return;
> > > +	}
> > > +
> > > +	res->a0 = uuid_hc.gprs[0];
> > > +	res->a1 = uuid_hc.gprs[1];
> > > +	res->a2 = uuid_hc.gprs[2];
> > > +	res->a3 = uuid_hc.gprs[3];
> > > +}
> > > +#endif
> > > +
> > >   bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
> > >   {
> > >   	struct arm_smccc_res res = {};
> > >   	uuid_t uuid;
> > >
> > > -
> > 	arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC
> > _ID, &res);
> > > +#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()).

Yes, this is how a Realm can talk to the Host hypervisor, i.e, 
RSI_HOST_CALL. In simpler terms, HVC is routed to Realm world for
Realms (e.g., a Paravisor running in Realm world Plane-0).
A Realm must always use RSI_HOST_CALL to reach the non-secure
hypervisor. RSI_HOST_CALL expects the arguments to be passed
in a "memory" area to preserve forward compatibility with
the SMCCC standards to allow for using the full argument/result
list.

The RMM does the job of copying the arguments from the Realm memory
to the rec_exit.gprs for consumption by the Host. The host can then
return the results in rec_entr.gprs, which then gets copied over
to the Realm memory area.

> Hi Catalin,
> 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]).
>
> In arch/arm64/kvm/rmi-exit.c, when a Realm guest triggers an
> RMI_EXIT_HOST_CALL, KVM intercepts it and invokes rec_exit_hvc():
>
> case RMI_EXIT_HOST_CALL:
> 	rec_exit_hvc(vcpu);
> 	kvm_make_request(KVM_REQ_RMI, vcpu);
> 	return ARM_EXCEPTION_TRAP;
>
> Inside rec_exit_hvc(), KVM copies the GPRs from the rec run structure
> into the vCPU registers and explicitly emulates a standard HVC
> exception by populating esr_el2:
>
> static void rec_exit_hvc(struct kvm_vcpu *vcpu)
> {
>          struct realm_rec *rec = &vcpu->arch.rec;
>          int i;
>
>          for (i = 0; i < REC_RUN_GPRS; i++)
>                  vcpu_set_reg(vcpu, i, rec->run->exit.gprs[i]);
>
>          vcpu->arch.fault.esr_el2 = (ESR_ELx_EC_HVC64 << ESR_ELx_EC_SHIFT) |
>                                       ESR_ELx_IL;
> }
>
> After doing so, it returns ARM_EXCEPTION_TRAP, causing KVM's generic
> exception handling loop (kvm_arch_vcpu_ioctl_run() -> handle_exit()) to
> route it straight into the standard handle_hvc() ->
> kvm_smccc_call_handler() path.
>
> 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.
>   
> > I thought realms should stick to the RSI interface and not try to guess
> > the host hypervisor. But if you do need this, a better fit would be in
> > hyperv_detect_via_smccc() (if realms don't boot with ACPI).
> >
> > I'll leave it to Sudeep or Suzuki to comment further.
> >
> > --
> > Catalin
>
> As I described above, this patch from Kameron should work fine.
>
> BTW, as Kameron mentioned in another reply, he better organized the
> code by moving the code in this patch into
> arch/arm64/hyperv/mshyperv.c: hyperv_detect_via_smccc().

Any Realm specific stuff must be handled accordingly in the 
"enlightened" path, not in the common code like this patch.

Cheers
Suzuki


> (technically, IMO this change is unnecessary)
>
> Thanks,
> Dexuan
>
> [1] https://gitlab.arm.com/linux-arm/linux-cca/-/tree/cca-host/v16
> [2] https://lore.kernel.org/all/20261031001412.4150488-3-kameroncarr@xxxxxxxxxxxxxxxxxxx/