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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

Hi

On 31/10/2026 04:47, Dexuan Cui wrote:
>> From: Catalin Marinas <catalin.marinas@arm.com>
>> 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@linux.microsoft.com/