[PATCH 0/2] use TPM device with CRB over FF-A when kernel boot with pkvm

[PATCH 0/2] use TPM device with CRB over FF-A when kernel boot with pkvm

[Yeoreum Yun]

To use TPM device iwth CRB over FF-A, it would be good to be compiled:
  - CONFIG_ARM_FFA_TRANSPORT as bulit-in
  - CONFIG_TCG_ARM_CRB_FFA as built-in

to integrate with IMA subsystem otherwise, it couldn't generate the
boot_aggreate log with the PCR value.

Unfortuately, kernel fails to probe the TPM device
when it boots with kvm-arm.mode=protected since the FF-A calls
(FFA_SEND_DIRECT_MSG/MSG2) are failed when CONFIG_ARM_FFA_TRANSPORT=y.

This patch series resolves failure of the TPM device when
kernel boots with kvm-arm.mode=protected and based on v6.18-rc3.

Yeoreum Yun (2):
  KVM: arm64: fix FF-A call failure when ff-a driver is built-in
  KVM: arm64: support optional calls of FF-A v1.2

 arch/arm64/kvm/hyp/nvhe/ffa.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)


base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

[Yeoreum Yun]

Until has_version_negotiated is set to true,
all FF-A function calls fail except FFA_VERSION.
The has_version_negotiated flag is set to true when
the first FFA_VERSION call is made after init_hyp_mode().

This works fine when the FF-A driver is built as a module,
since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
to set has_version_negotiated to true.

However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
all FF-A calls fail. This happens because ffa_init() runs before
kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
As a result, the hypervisor cannot set has_version_negotiated,
since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
(HCR_EL2.TSC is cleared before kvm_arm_init()).

Consequently, this causes failures when using EFI variable services
with secure partitions that rely on FFA_SEND_DIRECT_MSG.

To fix this, call hyp_ffa_post_init() and set has_version_negotiated
during hyp_ffa_init() when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y).

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 4e16f9b96f63..0ae87ff61758 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -984,5 +984,17 @@ int hyp_ffa_init(void *pages)
 	};
 
 	version_lock = __HYP_SPIN_LOCK_UNLOCKED;
+
+	if (IS_BUILTIN(CONFIG_ARM_FFA_TRANSPORT)) {
+		hyp_spin_lock(&version_lock);
+		if (hyp_ffa_post_init()) {
+			hyp_spin_unlock(&version_lock);
+			return -EOPNOTSUPP;
+		}
+
+		smp_store_release(&has_version_negotiated, true);
+		hyp_spin_unlock(&version_lock);
+	}
+
 	return 0;
 }
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

[Sebastian Ene]

On Mon, Oct 27, 2025 at 07:17:28PM +0000, Yeoreum Yun wrote:

Hi Yeoreum,

> Until has_version_negotiated is set to true,
> all FF-A function calls fail except FFA_VERSION.
> The has_version_negotiated flag is set to true when
> the first FFA_VERSION call is made after init_hyp_mode().
> 
> This works fine when the FF-A driver is built as a module,
> since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
> to set has_version_negotiated to true.
> 
> However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
> all FF-A calls fail. This happens because ffa_init() runs before
> kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
> As a result, the hypervisor cannot set has_version_negotiated,
> since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
> (HCR_EL2.TSC is cleared before kvm_arm_init()).
> 

I understand the reason behind the patch but this is problematic to have
the builtin driver load before pKVM because the hypervisor would be
un-aware of the host mapped buffers. (eg. the call from ffa_rxtx_map is
not trapped because it is too early). Essentially, you will end up
bypassing the hyp FF-A proxy which I think you will want to avoid.

> Consequently, this causes failures when using EFI variable services
> with secure partitions that rely on FFA_SEND_DIRECT_MSG.
> 
> To fix this, call hyp_ffa_post_init() and set has_version_negotiated
> during hyp_ffa_init() when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y).
> 
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 4e16f9b96f63..0ae87ff61758 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -984,5 +984,17 @@ int hyp_ffa_init(void *pages)
>  	};
>  
>  	version_lock = __HYP_SPIN_LOCK_UNLOCKED;
> +
> +	if (IS_BUILTIN(CONFIG_ARM_FFA_TRANSPORT)) {
> +		hyp_spin_lock(&version_lock);
> +		if (hyp_ffa_post_init()) {
> +			hyp_spin_unlock(&version_lock);
> +			return -EOPNOTSUPP;
> +		}
> +
> +		smp_store_release(&has_version_negotiated, true);
> +		hyp_spin_unlock(&version_lock);
> +	}
> +
>  	return 0;
>  }

Thanks,
Sebastian

> -- 
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> 

Re: [PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

[Yeoreum Yun]

Hi Sebastian,

> > Until has_version_negotiated is set to true,
> > all FF-A function calls fail except FFA_VERSION.
> > The has_version_negotiated flag is set to true when
> > the first FFA_VERSION call is made after init_hyp_mode().
> >
> > This works fine when the FF-A driver is built as a module,
> > since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
> > to set has_version_negotiated to true.
> >
> > However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
> > all FF-A calls fail. This happens because ffa_init() runs before
> > kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
> > As a result, the hypervisor cannot set has_version_negotiated,
> > since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
> > (HCR_EL2.TSC is cleared before kvm_arm_init()).
> >
>
> I understand the reason behind the patch but this is problematic to have
> the builtin driver load before pKVM because the hypervisor would be
> un-aware of the host mapped buffers. (eg. the call from ffa_rxtx_map is
> not trapped because it is too early). Essentially, you will end up
> bypassing the hyp FF-A proxy which I think you will want to avoid.

Ah. I've overlooed the ffa_rxtx_map proxy.
But unfortunately, some of depndency with the driver using arm_ffa
driver, ffa_init() should be called first then other drivers' initcall
(usually, these kind of driver defines its one initcall with
device_initcall()) (i.e) https://lore.kernel.org/all/20250618102302.2379029-1-yeoreum.yun@arm.com/.

Though I arm_ffa driver provide an API getting mapped rx/tx buffer,
But this seems to reverse dependency -- kvm depends on arm_ffa driver.

I’ve been thinking about some possible solutions,
but in my narrow idea, valid solution is kvm_arm_init() as
subsys_initcall_sync() and call kvm_init() in module_init() like
attached modification.

Do you have any idea?

Thanks.

------<&--------

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 870953b4a8a7..44711f3c7e04 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -65,7 +65,7 @@ DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);

 DECLARE_KVM_NVHE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);

-static bool vgic_present, kvm_arm_initialised;
+static bool vgic_present, in_hyp_mode, okvm_arm_early_initialised, kvm_arm_initialised;

 static DEFINE_PER_CPU(unsigned char, kvm_hyp_initialized);

@@ -2827,11 +2827,42 @@ void kvm_arch_irq_bypass_start(struct irq_bypass_consumer *cons)
        kvm_arm_resume_guest(irqfd->kvm);
 }

+static __init int kvm_arm_post_init(void)
+{
+       int err;
+
+       if (!kvm_arm_early_initialised)
+               return -ENODEV;
+
+       /*
+        * FIXME: Do something reasonable if kvm_init() fails after pKVM
+        * hypervisor protection is finalized.
+        */
+       err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
+       if (err) {
+               teardown_subsystems();
+               if (!in_hyp_mode)
+                       teardown_hyp_mode();
+               kvm_arm_vmid_alloc_free();
+               return err;
+       }
+
+       /*
+        * This should be called after initialization is done and failure isn't
+        * possible anymore.
+        */
+       if (!in_hyp_mode)
+               finalize_init_hyp_mode();
+
+       kvm_arm_initialised = true;
+       return 0;
+}
+
+
 /* Initialize Hyp-mode and memory mappings on all CPUs */
 static __init int kvm_arm_init(void)
 {
        int err;
-       bool in_hyp_mode;

        if (!is_hyp_mode_available()) {
                kvm_info("HYP mode not available\n");
@@ -2893,30 +2924,18 @@ static __init int kvm_arm_init(void)
                                     "h" : "n"),
                 cpus_have_final_cap(ARM64_HAS_NESTED_VIRT) ? "+NV2": "");

-       /*
-        * FIXME: Do something reasonable if kvm_init() fails after pKVM
-        * hypervisor protection is finalized.
-        */
-       err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
-       if (err)
-               goto out_subs;
-
-       /*
-        * This should be called after initialization is done and failure isn't
-        * possible anymore.
-        */
-       if (!in_hyp_mode)
-               finalize_init_hyp_mode();
-
-       kvm_arm_initialised = true;
+       kvm_arm_early_initialised = true;

-       return 0;
+#ifdef MODULE
+       err = kvm_arm_post_init();
+#endif
+       return err;

-out_subs:
-       teardown_subsystems();
 out_hyp:
-       if (!in_hyp_mode)
+       if (!in_hyp_mode) {
                teardown_hyp_mode();
+               in_hyp_mode = false;
+       }
 out_err:
        kvm_arm_vmid_alloc_free();
        return err;
@@ -2995,4 +3014,7 @@ enum kvm_mode kvm_get_mode(void)
        return kvm_mode;
 }

-module_init(kvm_arm_init);
+subsys_initcall_sync(kvm_arm_init);
+#ifndef MODULE
+module_init(kvm_arm_post_init);
+#endif

[...]

--
Sincerely,
Yeoreum Yun

Re: [PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

[Marc Zyngier]

On Fri, 31 Oct 2025 10:08:37 +0000,
Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> 
> Hi Sebastian,
> 
> > > Until has_version_negotiated is set to true,
> > > all FF-A function calls fail except FFA_VERSION.
> > > The has_version_negotiated flag is set to true when
> > > the first FFA_VERSION call is made after init_hyp_mode().
> > >
> > > This works fine when the FF-A driver is built as a module,
> > > since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
> > > to set has_version_negotiated to true.
> > >
> > > However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
> > > all FF-A calls fail. This happens because ffa_init() runs before
> > > kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
> > > As a result, the hypervisor cannot set has_version_negotiated,
> > > since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
> > > (HCR_EL2.TSC is cleared before kvm_arm_init()).
> > >
> >
> > I understand the reason behind the patch but this is problematic to have
> > the builtin driver load before pKVM because the hypervisor would be
> > un-aware of the host mapped buffers. (eg. the call from ffa_rxtx_map is
> > not trapped because it is too early). Essentially, you will end up
> > bypassing the hyp FF-A proxy which I think you will want to avoid.
> 
> Ah. I've overlooed the ffa_rxtx_map proxy.
> But unfortunately, some of depndency with the driver using arm_ffa
> driver, ffa_init() should be called first then other drivers' initcall
> (usually, these kind of driver defines its one initcall with
> device_initcall()) (i.e) https://lore.kernel.org/all/20250618102302.2379029-1-yeoreum.yun@arm.com/.
> 
> Though I arm_ffa driver provide an API getting mapped rx/tx buffer,
> But this seems to reverse dependency -- kvm depends on arm_ffa driver.

No it doesn't. KVM doesn't give a damn about the kernel FFA driver. It
just makes sure that the driver doesn't do anything stupid.

> I’ve been thinking about some possible solutions,
> but in my narrow idea, valid solution is kvm_arm_init() as
> subsys_initcall_sync() and call kvm_init() in module_init() like
> attached modification.
> 
> Do you have any idea?

There is no way we can accept such a change. It makes something
fragile even more brittle. If anything, make the FFA driver check for
KVM being initialised, and make the probing defer if not.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 1/2] KVM: arm64: fix FF-A call failure when ff-a driver is built-in

[Yeoreum Yun]

+Sudeep holla

Hi Marc,

> Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > Hi Sebastian,
> >
> > > > Until has_version_negotiated is set to true,
> > > > all FF-A function calls fail except FFA_VERSION.
> > > > The has_version_negotiated flag is set to true when
> > > > the first FFA_VERSION call is made after init_hyp_mode().
> > > >
> > > > This works fine when the FF-A driver is built as a module,
> > > > since ffa_init() is invoked after kvm_arm_init(), allowing do_ffa_version()
> > > > to set has_version_negotiated to true.
> > > >
> > > > However, when the FF-A driver is built-in (CONFIG_ARM_FFA_TRANSPORT=y),
> > > > all FF-A calls fail. This happens because ffa_init() runs before
> > > > kvm_arm_init() — the init level of ffa_init() is rootfs_initcall.
> > > > As a result, the hypervisor cannot set has_version_negotiated,
> > > > since the FFA_VERSION call made in ffa_init() does not trap to the hypervisor
> > > > (HCR_EL2.TSC is cleared before kvm_arm_init()).
> > > >
> > >
> > > I understand the reason behind the patch but this is problematic to have
> > > the builtin driver load before pKVM because the hypervisor would be
> > > un-aware of the host mapped buffers. (eg. the call from ffa_rxtx_map is
> > > not trapped because it is too early). Essentially, you will end up
> > > bypassing the hyp FF-A proxy which I think you will want to avoid.
> >
> > Ah. I've overlooed the ffa_rxtx_map proxy.
> > But unfortunately, some of depndency with the driver using arm_ffa
> > driver, ffa_init() should be called first then other drivers' initcall
> > (usually, these kind of driver defines its one initcall with
> > device_initcall()) (i.e) https://lore.kernel.org/all/20250618102302.2379029-1-yeoreum.yun@arm.com/.
> >
> > Though I arm_ffa driver provide an API getting mapped rx/tx buffer,
> > But this seems to reverse dependency -- kvm depends on arm_ffa driver.
>
> No it doesn't. KVM doesn't give a damn about the kernel FFA driver. It
> just makes sure that the driver doesn't do anything stupid.
>
> > I’ve been thinking about some possible solutions,
> > but in my narrow idea, valid solution is kvm_arm_init() as
> > subsys_initcall_sync() and call kvm_init() in module_init() like
> > attached modification.
> >
> > Do you have any idea?
>
> There is no way we can accept such a change. It makes something
> fragile even more brittle. If anything, make the FFA driver check for
> KVM being initialised, and make the probing defer if not.

The problematic situation is that we couldn't use "defer probe".
For example, IMA doesn't support the module build
and if ffa driver and related drivers using ffa driver defered,
IMA couldn't generated "boot aggregate log" which should be produced
at that time with PCR values in the TPM using CRB over FF-A.

Whatever monitoring KVM being intitialised, unless "defer probe" makes
a problematic situation, I think it seems meaningless.

@Sudeep. What do you think about it?


--
Sincerely,
Yeoreum Yun

[PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Yeoreum Yun]

To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
support the FF-A v1.2's optinal calls by querying whether
SPMC supports those.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 0ae87ff61758..9ded1c6369b9 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
 		ffa_to_smccc_res(res, ret);
 }
 
+static bool ffa_1_2_optional_calls_supported(u64 func_id)
+{
+	struct arm_smccc_1_2_regs res;
+
+	if (!smp_load_acquire(&has_version_negotiated) ||
+		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
+		return false;
+
+	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
+		.a0 = FFA_FEATURES,
+		.a1 = func_id,
+	}, &res);
+
+	return res.a0 == FFA_SUCCESS;
+}
+
 /*
  * Is a given FFA function supported, either by forwarding on directly
  * or by handling at EL2?
@@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
 	case FFA_NOTIFICATION_SET:
 	case FFA_NOTIFICATION_GET:
 	case FFA_NOTIFICATION_INFO_GET:
+		return false;
 	/* Optional interfaces added in FF-A 1.2 */
 	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
 	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
 	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
 	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
-		return false;
+		return ffa_1_2_optional_calls_supported(func_id);
 	}
 
 	return true;
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Ben Horgan]

Hi Levi,

On 10/27/25 19:17, Yeoreum Yun wrote:
> To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
> support the FF-A v1.2's optinal calls by querying whether
> SPMC supports those.
> 
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
>  arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 0ae87ff61758..9ded1c6369b9 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>  		ffa_to_smccc_res(res, ret);
>  }
>  
> +static bool ffa_1_2_optional_calls_supported(u64 func_id)
> +{
> +	struct arm_smccc_1_2_regs res;
> +
> +	if (!smp_load_acquire(&has_version_negotiated) ||
> +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
> +		return false;
> +
> +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> +		.a0 = FFA_FEATURES,
> +		.a1 = func_id,
> +	}, &res);
> +
> +	return res.a0 == FFA_SUCCESS;
> +}
> +
>  /*
>   * Is a given FFA function supported, either by forwarding on directly
>   * or by handling at EL2?
> @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
>  	case FFA_NOTIFICATION_SET:
>  	case FFA_NOTIFICATION_GET:
>  	case FFA_NOTIFICATION_INFO_GET:
> +		return false;
>  	/* Optional interfaces added in FF-A 1.2 */
>  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
>  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
>  	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */

Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
instances and not from the normal world.

>  	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
> -		return false;
> +		return ffa_1_2_optional_calls_supported(func_id);
>  	}

I don't think that an smc call here is the right thing to do. This changes this from a light 
weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.

Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.

So, just this change:

@@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
        case FFA_NOTIFICATION_GET:
        case FFA_NOTIFICATION_INFO_GET:
        /* Optional interfaces added in FF-A 1.2 */
-       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
        case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
        case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
        case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */

Am I missing something?

>  
>  	return true; 
Thanks,

Ben

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Yeoreum Yun]

Hi Ben,

> > To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
> > support the FF-A v1.2's optinal calls by querying whether
> > SPMC supports those.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 0ae87ff61758..9ded1c6369b9 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> >  		ffa_to_smccc_res(res, ret);
> >  }
> >
> > +static bool ffa_1_2_optional_calls_supported(u64 func_id)
> > +{
> > +	struct arm_smccc_1_2_regs res;
> > +
> > +	if (!smp_load_acquire(&has_version_negotiated) ||
> > +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
> > +		return false;
> > +
> > +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> > +		.a0 = FFA_FEATURES,
> > +		.a1 = func_id,
> > +	}, &res);
> > +
> > +	return res.a0 == FFA_SUCCESS;
> > +}
> > +
> >  /*
> >   * Is a given FFA function supported, either by forwarding on directly
> >   * or by handling at EL2?
> > @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
> >  	case FFA_NOTIFICATION_SET:
> >  	case FFA_NOTIFICATION_GET:
> >  	case FFA_NOTIFICATION_INFO_GET:
> > +		return false;
> >  	/* Optional interfaces added in FF-A 1.2 */
> >  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
> >  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
> >  	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
>
> Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
> instances and not from the normal world.

Thanks. in that case, we can return false for FFA_CONSOLE_LOG
unconditionally.

>
> >  	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
> > -		return false;
> > +		return ffa_1_2_optional_calls_supported(func_id);
> >  	}
>
> I don't think that an smc call here is the right thing to do. This changes this from a light
> weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
>
> Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
> and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
>
> So, just this change:
>
> @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
>         case FFA_NOTIFICATION_GET:
>         case FFA_NOTIFICATION_INFO_GET:
>         /* Optional interfaces added in FF-A 1.2 */
> -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
>         case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
>         case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
>         case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
>
> Am I missing something?

Nope. I think you don't think you miss anything and
I also think about it.

But, I'm not sure about "support" means in the pkvm about FF-A.
Anyway unless the SPMC doesn't support the specific FF-A ABI,
I don't know that's meaningful to return "TRUE" in here.
IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.

I'm not sure this inconsistency is allowed or not so as a defensive
perspective.

If that allows, I don't have a any special comment for this.

Thanks!

--
Sincerely,
Yeoreum Yun

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Ben Horgan]

Hi Levi,

On 10/28/25 21:06, Yeoreum Yun wrote:
> Hi Ben,
> 
>>> To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
>>> support the FF-A v1.2's optinal calls by querying whether
>>> SPMC supports those.
>>>
>>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>> ---
>>>  arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
>>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> index 0ae87ff61758..9ded1c6369b9 100644
>>> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>>>  		ffa_to_smccc_res(res, ret);
>>>  }
>>>
>>> +static bool ffa_1_2_optional_calls_supported(u64 func_id)
>>> +{
>>> +	struct arm_smccc_1_2_regs res;
>>> +
>>> +	if (!smp_load_acquire(&has_version_negotiated) ||
>>> +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
>>> +		return false;
>>> +
>>> +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
>>> +		.a0 = FFA_FEATURES,
>>> +		.a1 = func_id,
>>> +	}, &res);
>>> +
>>> +	return res.a0 == FFA_SUCCESS;
>>> +}
>>> +
>>>  /*
>>>   * Is a given FFA function supported, either by forwarding on directly
>>>   * or by handling at EL2?
>>> @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
>>>  	case FFA_NOTIFICATION_SET:
>>>  	case FFA_NOTIFICATION_GET:
>>>  	case FFA_NOTIFICATION_INFO_GET:
>>> +		return false;
>>>  	/* Optional interfaces added in FF-A 1.2 */
>>>  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
>>>  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
>>>  	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
>>
>> Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
>> instances and not from the normal world.
> 
> Thanks. in that case, we can return false for FFA_CONSOLE_LOG
> unconditionally.
> 
>>
>>>  	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
>>> -		return false;
>>> +		return ffa_1_2_optional_calls_supported(func_id);
>>>  	}
>>
>> I don't think that an smc call here is the right thing to do. This changes this from a light
>> weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
>>
>> Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
>> and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
>>
>> So, just this change:
>>
>> @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
>>         case FFA_NOTIFICATION_GET:
>>         case FFA_NOTIFICATION_INFO_GET:
>>         /* Optional interfaces added in FF-A 1.2 */
>> -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
>>         case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
>>         case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
>>         case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
>>
>> Am I missing something?
> 
> Nope. I think you don't think you miss anything and
> I also think about it.
> 
> But, I'm not sure about "support" means in the pkvm about FF-A.
> Anyway unless the SPMC doesn't support the specific FF-A ABI,
> I don't know that's meaningful to return "TRUE" in here.
> IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
> but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.

As I understand it, the ffa_call_supported() is used in two places:
1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
on the deny list.
2. To block ffa calls if they are on the deny list.

For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
denylist I think the behaviour is the same.

If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
a) an FFA_FEATURE call will return not supported
b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported

> 
> I'm not sure this inconsistency is allowed or not so as a defensive
> perspective.
> 
> If that allows, I don't have a any special comment for this.
> 
> Thanks!
> 
> --
> Sincerely,
> Yeoreum Yun

-- 
Thanks,

Ben

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Yeoreum Yun]

Hi Ben,

>
> On 10/28/25 21:06, Yeoreum Yun wrote:
> > Hi Ben,
> >
> >>> To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
> >>> support the FF-A v1.2's optinal calls by querying whether
> >>> SPMC supports those.
> >>>
> >>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> >>> ---
> >>>  arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
> >>>  1 file changed, 18 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> >>> index 0ae87ff61758..9ded1c6369b9 100644
> >>> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> >>> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> >>> @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> >>>  		ffa_to_smccc_res(res, ret);
> >>>  }
> >>>
> >>> +static bool ffa_1_2_optional_calls_supported(u64 func_id)
> >>> +{
> >>> +	struct arm_smccc_1_2_regs res;
> >>> +
> >>> +	if (!smp_load_acquire(&has_version_negotiated) ||
> >>> +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
> >>> +		return false;
> >>> +
> >>> +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> >>> +		.a0 = FFA_FEATURES,
> >>> +		.a1 = func_id,
> >>> +	}, &res);
> >>> +
> >>> +	return res.a0 == FFA_SUCCESS;
> >>> +}
> >>> +
> >>>  /*
> >>>   * Is a given FFA function supported, either by forwarding on directly
> >>>   * or by handling at EL2?
> >>> @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
> >>>  	case FFA_NOTIFICATION_SET:
> >>>  	case FFA_NOTIFICATION_GET:
> >>>  	case FFA_NOTIFICATION_INFO_GET:
> >>> +		return false;
> >>>  	/* Optional interfaces added in FF-A 1.2 */
> >>>  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
> >>>  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
> >>>  	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
> >>
> >> Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
> >> instances and not from the normal world.
> >
> > Thanks. in that case, we can return false for FFA_CONSOLE_LOG
> > unconditionally.
> >
> >>
> >>>  	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
> >>> -		return false;
> >>> +		return ffa_1_2_optional_calls_supported(func_id);
> >>>  	}
> >>
> >> I don't think that an smc call here is the right thing to do. This changes this from a light
> >> weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
> >>
> >> Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
> >> and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
> >>
> >> So, just this change:
> >>
> >> @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
> >>         case FFA_NOTIFICATION_GET:
> >>         case FFA_NOTIFICATION_INFO_GET:
> >>         /* Optional interfaces added in FF-A 1.2 */
> >> -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
> >>         case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
> >>         case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
> >>         case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
> >>
> >> Am I missing something?
> >
> > Nope. I think you don't think you miss anything and
> > I also think about it.
> >
> > But, I'm not sure about "support" means in the pkvm about FF-A.
> > Anyway unless the SPMC doesn't support the specific FF-A ABI,
> > I don't know that's meaningful to return "TRUE" in here.
> > IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
> > but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.
>
> As I understand it, the ffa_call_supported() is used in two places:
> 1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
> on the deny list.
> 2. To block ffa calls if they are on the deny list.
>
> For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
> denylist I think the behaviour is the same.
>
> If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
> a) an FFA_FEATURE call will return not supported
> b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported
>

Right! I've missed the FFA_FEATURE handles via default_host_smc_handler().
As you said, it just a deny list.

Thanks. I'll change it.


--
Sincerely,
Yeoreum Yun

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Per Larsen]

Hi Yeoreum,

On 10/29/25 2:36 PM, Yeoreum Yun wrote:
> Hi Ben,
> 
>>
>> On 10/28/25 21:06, Yeoreum Yun wrote:
>>> Hi Ben,
>>>
>>>>> To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
>>>>> support the FF-A v1.2's optinal calls by querying whether
>>>>> SPMC supports those.
>>>>>
>>>>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>>>> ---
>>>>>   arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
>>>>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>>>> index 0ae87ff61758..9ded1c6369b9 100644
>>>>> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
>>>>> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>>>> @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>>>>>   		ffa_to_smccc_res(res, ret);
>>>>>   }
>>>>>
>>>>> +static bool ffa_1_2_optional_calls_supported(u64 func_id)
>>>>> +{
>>>>> +	struct arm_smccc_1_2_regs res;
>>>>> +
>>>>> +	if (!smp_load_acquire(&has_version_negotiated) ||
>>>>> +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
>>>>> +		return false;
>>>>> +
>>>>> +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
>>>>> +		.a0 = FFA_FEATURES,
>>>>> +		.a1 = func_id,
>>>>> +	}, &res);
>>>>> +
>>>>> +	return res.a0 == FFA_SUCCESS;
>>>>> +}
>>>>> +
>>>>>   /*
>>>>>    * Is a given FFA function supported, either by forwarding on directly
>>>>>    * or by handling at EL2?
>>>>> @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
>>>>>   	case FFA_NOTIFICATION_SET:
>>>>>   	case FFA_NOTIFICATION_GET:
>>>>>   	case FFA_NOTIFICATION_INFO_GET:
>>>>> +		return false;
>>>>>   	/* Optional interfaces added in FF-A 1.2 */
>>>>>   	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
>>>>>   	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
>>>>>   	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
>>>>
>>>> Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
>>>> instances and not from the normal world.
>>>
>>> Thanks. in that case, we can return false for FFA_CONSOLE_LOG
>>> unconditionally.
>>>
>>>>
>>>>>   	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
>>>>> -		return false;
>>>>> +		return ffa_1_2_optional_calls_supported(func_id);
>>>>>   	}
>>>>
>>>> I don't think that an smc call here is the right thing to do. This changes this from a light
>>>> weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
>>>>
>>>> Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
>>>> and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
>>>>
>>>> So, just this change:
>>>>
>>>> @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
>>>>          case FFA_NOTIFICATION_GET:
>>>>          case FFA_NOTIFICATION_INFO_GET:
>>>>          /* Optional interfaces added in FF-A 1.2 */
>>>> -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
>>>>          case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
>>>>          case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
>>>>          case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
>>>>
>>>> Am I missing something?
>>>
>>> Nope. I think you don't think you miss anything and
>>> I also think about it.
>>>
>>> But, I'm not sure about "support" means in the pkvm about FF-A.
>>> Anyway unless the SPMC doesn't support the specific FF-A ABI,
>>> I don't know that's meaningful to return "TRUE" in here.
>>> IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
>>> but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.
>>
>> As I understand it, the ffa_call_supported() is used in two places:
>> 1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
>> on the deny list.
>> 2. To block ffa calls if they are on the deny list.
>>
>> For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
>> denylist I think the behaviour is the same.
>>
>> If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
>> a) an FFA_FEATURE call will return not supported
>> b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported
>>
> 
> Right! I've missed the FFA_FEATURE handles via default_host_smc_handler().
> As you said, it just a deny list.
> 
> Thanks. I'll change it.
Sorry to jump into the discussion very late. I uploaded a patch set 
which adds support for the FFA_MSG_SEND_DIRECT_REQ2 interface which was 
originally developed for the Android common kernels:

https://lore.kernel.org/all/20251030-host-direct-messages-v1-0-463e57871c8f@google.com/T/#t 


Since there appears to be an upstream use case for this functionality, 
it might be a good building block for the present patch set.

Thanks,
Per

Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

[Yeoreum Yun]

Hi Per,

>
> On 10/29/25 2:36 PM, Yeoreum Yun wrote:
> > Hi Ben,
> >
> > >
> > > On 10/28/25 21:06, Yeoreum Yun wrote:
> > > > Hi Ben,
> > > >
> > > > > > To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
> > > > > > support the FF-A v1.2's optinal calls by querying whether
> > > > > > SPMC supports those.
> > > > > >
> > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > ---
> > > > > >   arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
> > > > > >   1 file changed, 18 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > index 0ae87ff61758..9ded1c6369b9 100644
> > > > > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > > > > @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > > > >   		ffa_to_smccc_res(res, ret);
> > > > > >   }
> > > > > >
> > > > > > +static bool ffa_1_2_optional_calls_supported(u64 func_id)
> > > > > > +{
> > > > > > +	struct arm_smccc_1_2_regs res;
> > > > > > +
> > > > > > +	if (!smp_load_acquire(&has_version_negotiated) ||
> > > > > > +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
> > > > > > +		return false;
> > > > > > +
> > > > > > +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
> > > > > > +		.a0 = FFA_FEATURES,
> > > > > > +		.a1 = func_id,
> > > > > > +	}, &res);
> > > > > > +
> > > > > > +	return res.a0 == FFA_SUCCESS;
> > > > > > +}
> > > > > > +
> > > > > >   /*
> > > > > >    * Is a given FFA function supported, either by forwarding on directly
> > > > > >    * or by handling at EL2?
> > > > > > @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
> > > > > >   	case FFA_NOTIFICATION_SET:
> > > > > >   	case FFA_NOTIFICATION_GET:
> > > > > >   	case FFA_NOTIFICATION_INFO_GET:
> > > > > > +		return false;
> > > > > >   	/* Optional interfaces added in FF-A 1.2 */
> > > > > >   	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
> > > > > >   	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
> > > > > >   	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
> > > > >
> > > > > Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
> > > > > instances and not from the normal world.
> > > >
> > > > Thanks. in that case, we can return false for FFA_CONSOLE_LOG
> > > > unconditionally.
> > > >
> > > > >
> > > > > >   	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
> > > > > > -		return false;
> > > > > > +		return ffa_1_2_optional_calls_supported(func_id);
> > > > > >   	}
> > > > >
> > > > > I don't think that an smc call here is the right thing to do. This changes this from a light
> > > > > weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
> > > > >
> > > > > Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
> > > > > and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
> > > > >
> > > > > So, just this change:
> > > > >
> > > > > @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
> > > > >          case FFA_NOTIFICATION_GET:
> > > > >          case FFA_NOTIFICATION_INFO_GET:
> > > > >          /* Optional interfaces added in FF-A 1.2 */
> > > > > -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
> > > > >          case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
> > > > >          case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
> > > > >          case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Nope. I think you don't think you miss anything and
> > > > I also think about it.
> > > >
> > > > But, I'm not sure about "support" means in the pkvm about FF-A.
> > > > Anyway unless the SPMC doesn't support the specific FF-A ABI,
> > > > I don't know that's meaningful to return "TRUE" in here.
> > > > IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
> > > > but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.
> > >
> > > As I understand it, the ffa_call_supported() is used in two places:
> > > 1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
> > > on the deny list.
> > > 2. To block ffa calls if they are on the deny list.
> > >
> > > For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
> > > denylist I think the behaviour is the same.
> > >
> > > If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
> > > a) an FFA_FEATURE call will return not supported
> > > b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported
> > >
> >
> > Right! I've missed the FFA_FEATURE handles via default_host_smc_handler().
> > As you said, it just a deny list.
> >
> > Thanks. I'll change it.
> Sorry to jump into the discussion very late. I uploaded a patch set which
> adds support for the FFA_MSG_SEND_DIRECT_REQ2 interface which was originally
> developed for the Android common kernels:
>
> https://lore.kernel.org/all/20251030-host-direct-messages-v1-0-463e57871c8f@google.com/T/#t
>
>
> Since there appears to be an upstream use case for this functionality, it
> might be a good building block for the present patch set.

No worries and thanks for sharing.
I'll take a look and let me rebase this patch upon your one.

Thanks.

--
Sincerely,
Yeoreum Yun