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

[Dexuan Cui]

> 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()).

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().
(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/