[RFC PATCH 0/3] initalise ff-a after finalising pKVM

[RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Yeoreum Yun]

This patch is split out from the patchset [0] --
fix FF-A call failure with pKVM when the FF-A driver is built-in,
specifically the IMA-related part.

When pKVM is enabled, the FF-A driver must be initialised after pKVM.
Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
buffer information, leading to failures in FF-A calls.

Currently, pKVM initialisation completes at device_initcall_sync,
while ffa_init() runs at the device_initcall level.

So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
still be trapped even before finalise_pkvm() is invoked.
As a result, this issue has not been observed.

However, relying on above stuff is fragile.
Therefore, when pKVM is enabled, the FF-A infrastructure should be
initialised only after pKVM initialisation has been fully finalised.

To achieve this, introduce an ffa_root_dev ("arm-ffa") and
a corresponding driver to defer initialisation of the FF-A infrastructure
until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
when pKVM is enabled.

This patch is based on v7.1-rc2

Question:

FF-A initialisation can occur at late_initcall. Because it may be deferred,
some FF-A requests cannot be serviced at that stage.
A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.

Depending on the platform, the EFI runtime variable service runs with StandaloneMm
and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
may be deferred to late_initcall. In this case, load_uefi_certs()
can fail if it is invoked before the FF-A driver is initialised
via deferred_probe_initcall().

Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
seems not to have any problem since late_initcall and
late_initcall_sync are both of do_basic_setup() and it's before loading
init process. However, it is still unclear whether
it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
even before FF-A version negotiation since handler’s purpose seems to hook
certain memory operations, and DIRECT_MSG_REQ has been available
since FF-A specification v1.0.

Any feedback or alternative suggestions would be appreciated!

Link: https://lore.kernel.org/all/20260422162449.1814615-1-yeoreum.yun@arm.com/ [0]

Yeoreum Yun (3):
  arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
  firmware: arm_ffa: initialise ff-a after finalising pKVM
    initialisation
  security: integrity: call load_uefi_certs() at late_initcall_sync

 arch/arm64/kvm/arm.c                          |   8 +-
 arch/arm64/kvm/pkvm.c                         |  15 ++-
 drivers/firmware/arm_ffa/bus.c                | 125 +++++++++++++++++-
 drivers/firmware/arm_ffa/common.h             |  13 +-
 drivers/firmware/arm_ffa/driver.c             |  21 ++-
 drivers/firmware/arm_ffa/smccc.c              |   2 +-
 security/integrity/platform_certs/load_uefi.c |   2 +-
 7 files changed, 166 insertions(+), 20 deletions(-)


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

[RFC PATCH 1/3] arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled

[Yeoreum Yun]

This patch is a preparatory change to address dependency issues
between the FF-A driver and pKVM.

kvm_init() should be invoked from finalise_pkvm(),
as this is the point where pKVM initialisation is finalised and
the system transitions into the protected mode.

Deferring kvm_init() ensures that KVM is initialised only after pKVM has
fully established its protected environment.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/kvm/arm.c  |  8 +++++---
 arch/arm64/kvm/pkvm.c | 15 ++++++++++++++-
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 8bb2c7422cc8..663b1d447a9b 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -3025,9 +3025,11 @@ static __init int kvm_arm_init(void)
 	 * 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;
+	if (!is_protected_kvm_enabled()) {
+		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
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 053e4f733e4b..48b06d384570 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -17,6 +17,7 @@
 #include "hyp_constants.h"
 
 DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+EXPORT_SYMBOL_GPL(kvm_protected_mode_initialized);
 
 static struct memblock_region *hyp_memory = kvm_nvhe_sym(hyp_memory);
 static unsigned int *hyp_memblock_nr_ptr = &kvm_nvhe_sym(hyp_memblock_nr);
@@ -289,10 +290,22 @@ static int __init finalize_pkvm(void)
 	kmemleak_free_part(__hyp_rodata_start, __hyp_rodata_end - __hyp_rodata_start);
 	kmemleak_free_part_phys(hyp_mem_base, hyp_mem_size);
 
-	ret = pkvm_drop_host_privileges();
+	ret = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
 	if (ret)
+		goto out_err;
+
+	ret = pkvm_drop_host_privileges();
+	if (ret) {
 		pr_err("Failed to finalize Hyp protection: %d\n", ret);
+		kvm_exit();
+		goto out_err;
+	}
+
+	return 0;
 
+out_err:
+	kvm_unregister_perf_callbacks();
+	kvm_arm_vmid_alloc_free();
 	return ret;
 }
 device_initcall_sync(finalize_pkvm);
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Yeoreum Yun]

When pKVM is enabled, the FF-A driver must be initialised after pKVM.
Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
buffer information, leading to failures in FF-A calls.

Currently, pKVM initialisation completes at device_initcall_sync,
while ffa_init() runs at the device_initcall level.

So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
still be trapped even before finalise_pkvm() is invoked.
As a result, this issue has not been observed.

However, relying on above stuff is fragile.
Therefore, when pKVM is enabled, the FF-A infrastructure should be
initialised only after pKVM initialisation has been fully finalised.

To achieve this, introduce an ffa_root_dev ("arm-ffa") and
a corresponding driver to defer initialisation of the FF-A infrastructure
until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
when pKVM is enabled.

This change slightly alters the sysfs layout.

Previously, all FF-A devices were located directly under /sys/devices/,
for example:

  ls /sys/devices/
  ...
  arm-ffa-1
  arm-ffa-2
  arm-ffa-3
  ...

After this patch, all FF-A devices are placed under the FF-A root device
/sys/devices/arm-ffa/:

  ls /sys/devices/arm-ffa/
  ...
  arm-ffa-1
  arm-ffa-2
  arm-ffa-3
  ...

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 drivers/firmware/arm_ffa/bus.c    | 125 ++++++++++++++++++++++++++++--
 drivers/firmware/arm_ffa/common.h |  13 +++-
 drivers/firmware/arm_ffa/driver.c |  21 +++--
 drivers/firmware/arm_ffa/smccc.c  |   2 +-
 4 files changed, 146 insertions(+), 15 deletions(-)

diff --git a/drivers/firmware/arm_ffa/bus.c b/drivers/firmware/arm_ffa/bus.c
index 9576862d89c4..ddb352806d59 100644
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -13,11 +13,14 @@
 #include <linux/slab.h>
 #include <linux/types.h>
 
+#include <asm/virt.h>
+
 #include "common.h"
 
 #define FFA_UEVENT_MODALIAS_FMT	"arm_ffa:%04x:%pUb"
 
 static DEFINE_IDA(ffa_bus_id);
+static struct ffa_device *ffa_root_dev;
 
 static int ffa_device_match(struct device *dev, const struct device_driver *drv)
 {
@@ -27,7 +30,13 @@ static int ffa_device_match(struct device *dev, const struct device_driver *drv)
 	id_table = to_ffa_driver(drv)->id_table;
 	ffa_dev = to_ffa_dev(dev);
 
-	while (!uuid_is_null(&id_table->uuid)) {
+	if (is_ffa_root_device(ffa_dev)) {
+		if (!id_table)
+			return 1;
+		return 0;
+	}
+
+	while (id_table && !uuid_is_null(&id_table->uuid)) {
 		/*
 		 * FF-A v1.0 doesn't provide discovery of UUIDs, just the
 		 * partition IDs, so match it unconditionally here and handle
@@ -50,7 +59,7 @@ static int ffa_device_probe(struct device *dev)
 	struct ffa_device *ffa_dev = to_ffa_dev(dev);
 
 	/* UUID can be still NULL with FF-A v1.0, so just skip probing them */
-	if (uuid_is_null(&ffa_dev->uuid))
+	if (!is_ffa_root_device(ffa_dev) && uuid_is_null(&ffa_dev->uuid))
 		return -ENODEV;
 
 	return ffa_drv->probe(ffa_dev);
@@ -68,6 +77,9 @@ static int ffa_device_uevent(const struct device *dev, struct kobj_uevent_env *e
 {
 	const struct ffa_device *ffa_dev = to_ffa_dev(dev);
 
+	if (is_ffa_root_device(ffa_dev))
+		return 0;
+
 	return add_uevent_var(env, "MODALIAS=" FFA_UEVENT_MODALIAS_FMT,
 			      ffa_dev->vm_id, &ffa_dev->uuid);
 }
@@ -114,7 +126,6 @@ const struct bus_type ffa_bus_type = {
 	.probe		= ffa_device_probe,
 	.remove		= ffa_device_remove,
 	.uevent		= ffa_device_uevent,
-	.dev_groups	= ffa_device_attributes_groups,
 };
 EXPORT_SYMBOL_GPL(ffa_bus_type);
 
@@ -149,13 +160,18 @@ static void ffa_release_device(struct device *dev)
 {
 	struct ffa_device *ffa_dev = to_ffa_dev(dev);
 
-	ida_free(&ffa_bus_id, ffa_dev->id);
+	if (!is_ffa_root_device(ffa_dev))
+		ida_free(&ffa_bus_id, ffa_dev->id);
 	kfree(ffa_dev);
 }
 
 static int __ffa_devices_unregister(struct device *dev, void *data)
 {
-	device_unregister(dev);
+	struct ffa_device *ffa_dev = to_ffa_dev(dev);
+
+	/* ffa_root_dev will be removed in arm_ffa_bus_exit(). */
+	if (!is_ffa_root_device(ffa_dev))
+		device_unregister(dev);
 
 	return 0;
 }
@@ -195,6 +211,10 @@ ffa_device_register(const struct ffa_partition_info *part_info,
 	int id, ret;
 	struct device *dev;
 	struct ffa_device *ffa_dev;
+	struct device_link *link;
+
+	if (!ffa_root_dev)
+		return NULL;
 
 	if (!part_info)
 		return NULL;
@@ -213,6 +233,8 @@ ffa_device_register(const struct ffa_partition_info *part_info,
 	dev->bus = &ffa_bus_type;
 	dev->release = ffa_release_device;
 	dev->dma_mask = &dev->coherent_dma_mask;
+	dev->parent = &ffa_root_dev->dev;
+	dev->groups = ffa_device_attributes_groups;
 	dev_set_name(&ffa_dev->dev, "arm-ffa-%d", id);
 
 	ffa_dev->id = id;
@@ -221,7 +243,18 @@ ffa_device_register(const struct ffa_partition_info *part_info,
 	ffa_dev->ops = ops;
 	uuid_copy(&ffa_dev->uuid, &part_info->uuid);
 
-	ret = device_register(&ffa_dev->dev);
+	device_initialize(dev);
+
+	link = device_link_add(dev, &ffa_root_dev->dev,
+			       DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOPROBE_CONSUMER);
+	if (!link) {
+		dev_err(dev, "unable to link device %s\n", dev_name(dev));
+		device_link_del(link);
+		put_device(dev);
+		return NULL;
+	}
+
+	ret = device_add(dev);
 	if (ret) {
 		dev_err(dev, "unable to register device %s err=%d\n",
 			dev_name(dev), ret);
@@ -242,15 +275,93 @@ void ffa_device_unregister(struct ffa_device *ffa_dev)
 }
 EXPORT_SYMBOL_GPL(ffa_device_unregister);
 
+static int __init ffa_root_device_register(void)
+{
+	int ret;
+	struct device *dev;
+	struct ffa_device *ffa_dev;
+
+	ffa_dev = kzalloc_obj(*ffa_dev);
+	if (!ffa_dev) {
+		return -ENOMEM;
+	}
+
+	dev = &ffa_dev->dev;
+	dev->bus = &ffa_bus_type;
+	dev->release = ffa_release_device;
+	dev->dma_mask = &dev->coherent_dma_mask;
+	dev_set_name(&ffa_dev->dev, "%s", "arm-ffa");
+
+	ffa_dev->id = FFA_ROOT_DEV_ID;
+
+	ret = device_register(&ffa_dev->dev);
+	if (ret) {
+		dev_err(dev, "unable to register root device. err=%d\n", ret);
+		put_device(dev);
+		return ret;
+	}
+
+	ffa_root_dev = ffa_dev;
+
+	return 0;
+}
+
+static void ffa_root_device_unregister(void)
+{
+	ffa_device_unregister(ffa_root_dev);
+	ffa_root_dev = NULL;
+}
+
+static int ffa_root_device_probe(struct ffa_device *ffa_dev)
+{
+	if (!is_ffa_root_device(ffa_dev))
+		return -EINVAL;
+
+	if (is_protected_kvm_enabled() && !is_pkvm_initialized())
+		return -EPROBE_DEFER;
+
+	return ffa_core_init();
+}
+
+static struct ffa_driver ffa_root_dev_driver = {
+	.name = "arm-ffa",
+	.probe = ffa_root_device_probe,
+	.id_table = NULL,
+};
+
+int ffa_root_device_driver_register(void)
+{
+	return ffa_driver_register(&ffa_root_dev_driver, THIS_MODULE, KBUILD_MODNAME);
+}
+
+static void ffa_root_device_driver_unregister(void)
+{
+	ffa_driver_unregister(&ffa_root_dev_driver);
+}
+
 static int __init arm_ffa_bus_init(void)
 {
-	return bus_register(&ffa_bus_type);
+	int ret;
+
+	ret = bus_register(&ffa_bus_type);
+	if (ret)
+		return ret;
+
+	ret = ffa_root_device_register();
+	if (ret) {
+		bus_unregister(&ffa_bus_type);
+		return ret;
+	}
+
+	return 0;
 }
 subsys_initcall(arm_ffa_bus_init);
 
 static void __exit arm_ffa_bus_exit(void)
 {
 	ffa_devices_unregister();
+	ffa_root_device_unregister();
+	ffa_root_device_driver_unregister();
 	bus_unregister(&ffa_bus_type);
 	ida_destroy(&ffa_bus_id);
 }
diff --git a/drivers/firmware/arm_ffa/common.h b/drivers/firmware/arm_ffa/common.h
index 9c6425a81d0d..32ffe41c3cfc 100644
--- a/drivers/firmware/arm_ffa/common.h
+++ b/drivers/firmware/arm_ffa/common.h
@@ -10,17 +10,26 @@
 #include <linux/arm-smccc.h>
 #include <linux/err.h>
 
+#define FFA_ROOT_DEV_ID	(0)
+
 typedef struct arm_smccc_1_2_regs ffa_value_t;
 
 typedef void (ffa_fn)(ffa_value_t, ffa_value_t *);
 
 bool ffa_device_is_valid(struct ffa_device *ffa_dev);
 void ffa_device_match_uuid(struct ffa_device *ffa_dev, const uuid_t *uuid);
+int ffa_root_device_driver_register(void);
+int ffa_core_init(void);
+
+static __always_inline bool is_ffa_root_device(const struct ffa_device *ffa_dev)
+{
+	return ffa_dev->id == FFA_ROOT_DEV_ID;
+}
 
 #ifdef CONFIG_ARM_FFA_SMCCC
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn);
+int ffa_transport_init(ffa_fn **invoke_ffa_fn);
 #else
-static inline int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+static inline int ffa_transport_init(ffa_fn **invoke_ffa_fn)
 {
 	return -EOPNOTSUPP;
 }
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..c41e7ed4eac8 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1610,6 +1610,9 @@ ffa_bus_notifier(struct notifier_block *nb, unsigned long action, void *data)
 		struct ffa_driver *ffa_drv = to_ffa_driver(dev->driver);
 		const struct ffa_device_id *id_table = ffa_drv->id_table;
 
+		if (is_ffa_root_device(fdev))
+			return NOTIFY_DONE;
+
 		/*
 		 * FF-A v1.1 provides UUID for each partition as part of the
 		 * discovery API, the discovered UUID must be populated in the
@@ -2029,7 +2032,7 @@ static void ffa_notifications_setup(void)
 	ffa_notifications_cleanup();
 }
 
-static int __init ffa_init(void)
+int ffa_core_init(void)
 {
 	int ret;
 	u32 buf_sz;
@@ -2106,16 +2109,24 @@ static int __init ffa_init(void)
 	kfree(drv_info);
 	return ret;
 }
-rootfs_initcall(ffa_init);
+
+static int __init ffa_init(void)
+{
+	return ffa_root_device_driver_register();
+}
+device_initcall(ffa_init);
 
 static void __exit ffa_exit(void)
 {
 	ffa_notifications_cleanup();
 	ffa_partitions_cleanup();
 	ffa_rxtx_unmap();
-	free_pages_exact(drv_info->tx_buffer, drv_info->rxtx_bufsz);
-	free_pages_exact(drv_info->rx_buffer, drv_info->rxtx_bufsz);
-	kfree(drv_info);
+
+	if (drv_info) {
+		free_pages_exact(drv_info->tx_buffer, drv_info->rxtx_bufsz);
+		free_pages_exact(drv_info->rx_buffer, drv_info->rxtx_bufsz);
+		kfree(drv_info);
+	}
 }
 module_exit(ffa_exit);
 
diff --git a/drivers/firmware/arm_ffa/smccc.c b/drivers/firmware/arm_ffa/smccc.c
index 4d85bfff0a4e..e6125dd9f58f 100644
--- a/drivers/firmware/arm_ffa/smccc.c
+++ b/drivers/firmware/arm_ffa/smccc.c
@@ -17,7 +17,7 @@ static void __arm_ffa_fn_hvc(ffa_value_t args, ffa_value_t *res)
 	arm_smccc_1_2_hvc(&args, res);
 }
 
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+int ffa_transport_init(ffa_fn **invoke_ffa_fn)
 {
 	enum arm_smccc_conduit conduit;
 
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Sudeep Holla]

On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> buffer information, leading to failures in FF-A calls.
> 
> Currently, pKVM initialisation completes at device_initcall_sync,
> while ffa_init() runs at the device_initcall level.
> 
> So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> still be trapped even before finalise_pkvm() is invoked.
> As a result, this issue has not been observed.
> 
> However, relying on above stuff is fragile.
> Therefore, when pKVM is enabled, the FF-A infrastructure should be
> initialised only after pKVM initialisation has been fully finalised.
> 
> To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> a corresponding driver to defer initialisation of the FF-A infrastructure
> until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> when pKVM is enabled.
> 

I don't like this whole ffa root device design.
Two question for now:
1. Can FF-A be a module on systems with pKVM which removes the need for all
   this dance done here ?
2. If it is a requirement to have this built-in, I prefer to add a probe
   and defer it instead of this root ffa device.

-- 
Regards,
Sudeep

Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Yeoreum Yun]

Hi Sudeep,

> On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > buffer information, leading to failures in FF-A calls.
> > 
> > Currently, pKVM initialisation completes at device_initcall_sync,
> > while ffa_init() runs at the device_initcall level.
> > 
> > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > still be trapped even before finalise_pkvm() is invoked.
> > As a result, this issue has not been observed.
> > 
> > However, relying on above stuff is fragile.
> > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > initialised only after pKVM initialisation has been fully finalised.
> > 
> > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > a corresponding driver to defer initialisation of the FF-A infrastructure
> > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > when pKVM is enabled.
> > 
> 
> I don't like this whole ffa root device design.
> Two question for now:
> 1. Can FF-A be a module on systems with pKVM which removes the need for all
>    this dance done here ?

But this means we reduce the other feature e.x) IMA with TPM over
FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
to build FF-A driver with built-in.

> 2. If it is a requirement to have this built-in, I prefer to add a probe
>    and defer it instead of this root ffa device.

But, How? anyway all of FF-A device & driver couldn't be probed unless
FF-A initialisation is finished and How can we trigger FF-A initailise
after pKVM finish its initialisation?

The problem is ff-a intiailisation happens before pKVM finish its
initailasation and to do defer probe, it should use dd-model and
As we discussed in other thread, notifier couldn't be a soluation.

Could you let me share other way I'm missing?

Thanks!

> -- 
> Regards,
> Sudeep

-- 
Sincerely,
Yeoreum Yun

Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Sudeep Holla]

On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> Hi Sudeep,
> 
> > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > buffer information, leading to failures in FF-A calls.
> > > 
> > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > while ffa_init() runs at the device_initcall level.
> > > 
> > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > still be trapped even before finalise_pkvm() is invoked.
> > > As a result, this issue has not been observed.
> > > 
> > > However, relying on above stuff is fragile.
> > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > initialised only after pKVM initialisation has been fully finalised.
> > > 
> > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > when pKVM is enabled.
> > > 
> > 
> > I don't like this whole ffa root device design.
> > Two question for now:
> > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> >    this dance done here ?
> 
> But this means we reduce the other feature e.x) IMA with TPM over
> FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> to build FF-A driver with built-in.
> 
> > 2. If it is a requirement to have this built-in, I prefer to add a probe
> >    and defer it instead of this root ffa device.
> 
> But, How? anyway all of FF-A device & driver couldn't be probed unless
> FF-A initialisation is finished and How can we trigger FF-A initailise
> after pKVM finish its initialisation?
> 
> The problem is ff-a intiailisation happens before pKVM finish its
> initailasation and to do defer probe, it should use dd-model and
> As we discussed in other thread, notifier couldn't be a soluation.
> 
> Could you let me share other way I'm missing?
> 

Will something like below work ? If we add DT bindings, then we can add
of_match_table and drop the platform device creation. Also we can adjust
the parent device the way you have done by a simple change(not done in
this untested/not compiled change).

Regards,
Sudeep

-->8

firmware: arm_ffa: Register core as a platform driver

Move the FF-A core bring-up and teardown paths into platform driver
probe and remove callbacks, and register a synthetic arm-ffa platform
device to bind the driver.

This makes the FF-A core lifetime follow the driver model while keeping
the device creation internal to the FF-A core. The probe path can now
return normal driver-model errors, including probe deferral when pKVM is
enabled but not yet initialized.

Since the transport selection now happens from the platform probe path,
drop the __init annotation from ffa_transport_init().

Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
 drivers/firmware/arm_ffa/common.h |  4 +--
 drivers/firmware/arm_ffa/driver.c | 55 +++++++++++++++++++++++++++----
 drivers/firmware/arm_ffa/smccc.c  |  2 +-
 3 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/arm_ffa/common.h b/drivers/firmware/arm_ffa/common.h
index 9c6425a81d0d..5cdf4bd222c6 100644
--- a/drivers/firmware/arm_ffa/common.h
+++ b/drivers/firmware/arm_ffa/common.h
@@ -18,9 +18,9 @@ bool ffa_device_is_valid(struct ffa_device *ffa_dev);
 void ffa_device_match_uuid(struct ffa_device *ffa_dev, const uuid_t *uuid);
 
 #ifdef CONFIG_ARM_FFA_SMCCC
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn);
+int ffa_transport_init(ffa_fn **invoke_ffa_fn);
 #else
-static inline int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+static inline int ffa_transport_init(ffa_fn **invoke_ffa_fn)
 {
 	return -EOPNOTSUPP;
 }
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..d000727889f4 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -36,6 +36,7 @@
 #include <linux/mm.h>
 #include <linux/mutex.h>
 #include <linux/of_irq.h>
+#include <linux/platform_device.h>
 #include <linux/scatterlist.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
@@ -46,6 +47,7 @@
 
 #define FFA_DRIVER_VERSION	FFA_VERSION_1_2
 #define FFA_MIN_VERSION		FFA_VERSION_1_0
+#define FFA_PLATFORM_NAME	"arm-ffa"
 
 #define SENDER_ID_MASK		GENMASK(31, 16)
 #define RECEIVER_ID_MASK	GENMASK(15, 0)
@@ -114,6 +116,7 @@ struct ffa_drv_info {
 };
 
 static struct ffa_drv_info *drv_info;
+static struct platform_device *ffa_pdev;
 
 /*
  * The driver must be able to support all the versions from the earliest
@@ -2029,12 +2032,15 @@ static void ffa_notifications_setup(void)
 	ffa_notifications_cleanup();
 }
 
-static int __init ffa_init(void)
+static int ffa_probe(struct platform_device *pdev)
 {
 	int ret;
 	u32 buf_sz;
 	size_t rxtx_bufsz = SZ_4K;
 
+	if (is_protected_kvm_enabled() && !is_pkvm_initialized())
+		return -EPROBE_DEFER;
+
 	ret = ffa_transport_init(&invoke_ffa_fn);
 	if (ret)
 		return ret;
@@ -2042,6 +2048,7 @@ static int __init ffa_init(void)
 	drv_info = kzalloc_obj(*drv_info);
 	if (!drv_info)
 		return -ENOMEM;
+	platform_set_drvdata(pdev, drv_info);
 
 	ret = ffa_version_check(&drv_info->version);
 	if (ret)
@@ -2103,19 +2110,55 @@ static int __init ffa_init(void)
 		free_pages_exact(drv_info->tx_buffer, rxtx_bufsz);
 	free_pages_exact(drv_info->rx_buffer, rxtx_bufsz);
 free_drv_info:
+	platform_set_drvdata(pdev, NULL);
 	kfree(drv_info);
+	drv_info = NULL;
 	return ret;
 }
-rootfs_initcall(ffa_init);
 
-static void __exit ffa_exit(void)
+static void ffa_remove(struct platform_device *pdev)
 {
+	struct ffa_drv_info *info = platform_get_drvdata(pdev);
+
 	ffa_notifications_cleanup();
 	ffa_partitions_cleanup();
 	ffa_rxtx_unmap();
-	free_pages_exact(drv_info->tx_buffer, drv_info->rxtx_bufsz);
-	free_pages_exact(drv_info->rx_buffer, drv_info->rxtx_bufsz);
-	kfree(drv_info);
+	free_pages_exact(info->tx_buffer, info->rxtx_bufsz);
+	free_pages_exact(info->rx_buffer, info->rxtx_bufsz);
+	kfree(info);
+	platform_set_drvdata(pdev, NULL);
+	drv_info = NULL;
+}
+
+static struct platform_driver ffa_driver = {
+	.remove = ffa_remove,
+	.driver = {
+		.name = FFA_PLATFORM_NAME,
+	},
+};
+
+static int __init ffa_init(void)
+{
+	int ret;
+
+	ffa_pdev = platform_device_register_simple(FFA_PLATFORM_NAME,
+						   PLATFORM_DEVID_NONE,
+						   NULL, 0);
+	if (IS_ERR(ffa_pdev))
+		return PTR_ERR(ffa_pdev);
+
+	ret = platform_driver_probe(&ffa_driver, ffa_probe);
+	if (ret)
+		platform_device_unregister(ffa_pdev);
+
+	return ret;
+}
+module_init(ffa_init);
+
+static void __exit ffa_exit(void)
+{
+	platform_device_unregister(ffa_pdev);
+	platform_driver_unregister(&ffa_driver);
 }
 module_exit(ffa_exit);
 
diff --git a/drivers/firmware/arm_ffa/smccc.c b/drivers/firmware/arm_ffa/smccc.c
index 4d85bfff0a4e..e6125dd9f58f 100644
--- a/drivers/firmware/arm_ffa/smccc.c
+++ b/drivers/firmware/arm_ffa/smccc.c
@@ -17,7 +17,7 @@ static void __arm_ffa_fn_hvc(ffa_value_t args, ffa_value_t *res)
 	arm_smccc_1_2_hvc(&args, res);
 }
 
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+int ffa_transport_init(ffa_fn **invoke_ffa_fn)
 {
 	enum arm_smccc_conduit conduit;
 
-- 
2.43.0

Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation

[Yeoreum Yun]

Hi Sudeep,

> On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> > 
> > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > buffer information, leading to failures in FF-A calls.
> > > > 
> > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > while ffa_init() runs at the device_initcall level.
> > > > 
> > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > still be trapped even before finalise_pkvm() is invoked.
> > > > As a result, this issue has not been observed.
> > > > 
> > > > However, relying on above stuff is fragile.
> > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > initialised only after pKVM initialisation has been fully finalised.
> > > > 
> > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > when pKVM is enabled.
> > > > 
> > > 
> > > I don't like this whole ffa root device design.
> > > Two question for now:
> > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > >    this dance done here ?
> > 
> > But this means we reduce the other feature e.x) IMA with TPM over
> > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > to build FF-A driver with built-in.
> > 
> > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > >    and defer it instead of this root ffa device.
> > 
> > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > FF-A initialisation is finished and How can we trigger FF-A initailise
> > after pKVM finish its initialisation?
> > 
> > The problem is ff-a intiailisation happens before pKVM finish its
> > initailasation and to do defer probe, it should use dd-model and
> > As we discussed in other thread, notifier couldn't be a soluation.
> > 
> > Could you let me share other way I'm missing?
> > 
> 
> Will something like below work ?

It might work and when I write the code I thougt about whether to
use add platform device but I didn't find why this is better than
to create root device of FF-A (anyway creating a simple platform device
for FF-A seems similar to create root device)
If you don't mind why it would be better than to create FF-A root
device in FF-A bus?

> If we add DT bindings, then we can add
> of_match_table and drop the platform device creation. Also we can adjust
> the parent device the way you have done by a simple change(not done in
> this untested/not compiled change).

Might for a DT, but do we need to platform device creation for ACPI case
anyway?


[...]

-- 
Sincerely,
Yeoreum Yun

[RFC PATCH 3/3] security: integrity: call load_uefi_certs() at late_initcall_sync

[Yeoreum Yun]

In the arm64 pKVM environment, all FF-A requests fail until the FF-A
driver is initialized, as the FF-A version is not negotiated with the
hypervisor beforehand.

When FF-A is built-in and pKVM is enabled, pKVM
finalises its initialization at the device_initcall_sync level,
while the FF-A driver is initialized later at the late_initcall stage
via deferred probe.

When the EFI variable service runs with StandaloneMm, it uses
FFA_DIRECT_MSG to access EFI variables. As a result,
load_uefi_certs() always fails in this environment.

To address this issue, defer load_uefi_certs() to the
late_initcall_sync level.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 security/integrity/platform_certs/load_uefi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index c0d6948446c3..cc2b879df5b6 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -235,4 +235,4 @@ static int __init load_uefi_certs(void)
 
 	return rc;
 }
-late_initcall(load_uefi_certs);
+late_initcall_sync(load_uefi_certs);
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Ben Horgan]

Hi Levi,

On 5/5/26 10:54, Yeoreum Yun wrote:
> This patch is split out from the patchset [0] --
> fix FF-A call failure with pKVM when the FF-A driver is built-in,
> specifically the IMA-related part.
> 
> When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> buffer information, leading to failures in FF-A calls.
> 
> Currently, pKVM initialisation completes at device_initcall_sync,
> while ffa_init() runs at the device_initcall level.
> 
> So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> still be trapped even before finalise_pkvm() is invoked.
> As a result, this issue has not been observed.
> 
> However, relying on above stuff is fragile.
> Therefore, when pKVM is enabled, the FF-A infrastructure should be
> initialised only after pKVM initialisation has been fully finalised.
> 
> To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> a corresponding driver to defer initialisation of the FF-A infrastructure
> until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> when pKVM is enabled.
> 
> This patch is based on v7.1-rc2
> 
> Question:
> 
> FF-A initialisation can occur at late_initcall. Because it may be deferred,
> some FF-A requests cannot be serviced at that stage.
> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> 
> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> may be deferred to late_initcall. In this case, load_uefi_certs()
> can fail if it is invoked before the FF-A driver is initialised
> via deferred_probe_initcall().
> 
> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> seems not to have any problem since late_initcall and
> late_initcall_sync are both of do_basic_setup() and it's before loading
> init process. However, it is still unclear whether
> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()

The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:

Section 13.2.2 says:

"If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
the version must happen before an invocation of any other FF-A ABI."

and a bit further down

"Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."

I would have thought that an SP would only go into the waiting state once the version negotiation is done.

Thanks,

Ben

> even before FF-A version negotiation since handler’s purpose seems to hook
> certain memory operations, and DIRECT_MSG_REQ has been available
> since FF-A specification v1.0.
> 
> Any feedback or alternative suggestions would be appreciated!
> 
> Link: https://lore.kernel.org/all/20260422162449.1814615-1-yeoreum.yun@arm.com/ [0]
> 
> Yeoreum Yun (3):
>   arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
>   firmware: arm_ffa: initialise ff-a after finalising pKVM
>     initialisation
>   security: integrity: call load_uefi_certs() at late_initcall_sync
> 
>  arch/arm64/kvm/arm.c                          |   8 +-
>  arch/arm64/kvm/pkvm.c                         |  15 ++-
>  drivers/firmware/arm_ffa/bus.c                | 125 +++++++++++++++++-
>  drivers/firmware/arm_ffa/common.h             |  13 +-
>  drivers/firmware/arm_ffa/driver.c             |  21 ++-
>  drivers/firmware/arm_ffa/smccc.c              |   2 +-
>  security/integrity/platform_certs/load_uefi.c |   2 +-
>  7 files changed, 166 insertions(+), 20 deletions(-)
> 
> 
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32

Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Yeoreum Yun]

Hi Ben,

> Hi Levi,
> 
> On 5/5/26 10:54, Yeoreum Yun wrote:
> > This patch is split out from the patchset [0] --
> > fix FF-A call failure with pKVM when the FF-A driver is built-in,
> > specifically the IMA-related part.
> > 
> > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > buffer information, leading to failures in FF-A calls.
> > 
> > Currently, pKVM initialisation completes at device_initcall_sync,
> > while ffa_init() runs at the device_initcall level.
> > 
> > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > still be trapped even before finalise_pkvm() is invoked.
> > As a result, this issue has not been observed.
> > 
> > However, relying on above stuff is fragile.
> > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > initialised only after pKVM initialisation has been fully finalised.
> > 
> > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > a corresponding driver to defer initialisation of the FF-A infrastructure
> > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > when pKVM is enabled.
> > 
> > This patch is based on v7.1-rc2
> > 
> > Question:
> > 
> > FF-A initialisation can occur at late_initcall. Because it may be deferred,
> > some FF-A requests cannot be serviced at that stage.
> > A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> > 
> > Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> > and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> > may be deferred to late_initcall. In this case, load_uefi_certs()
> > can fail if it is invoked before the FF-A driver is initialised
> > via deferred_probe_initcall().
> > 
> > Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> > seems not to have any problem since late_initcall and
> > late_initcall_sync are both of do_basic_setup() and it's before loading
> > init process. However, it is still unclear whether
> > it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
> 
> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
> 
> Section 13.2.2 says:
> 
> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> the version must happen before an invocation of any other FF-A ABI."
> 
> and a bit further down
> 
> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
> 
> I would have thought that an SP would only go into the waiting state once the version negotiation is done.

I mean the negotiation between hypervisor and ff-a driver.
actually the version negotiation is done with SPMC in
hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
just choose the lower version between version requested from ff-a driver
and negotiated version with hypervisor and SPMC.

So, the version negotiation is already done with SPMC
but with FF-A driver with hypervisor is not yet.
However, DIRECT_MSG_REQ has supported from v1.0 
In this situation, is there any reason not to send DIRECT_REQ_MSG?

> 
> > even before FF-A version negotiation since handler’s purpose seems to hook
> > certain memory operations, and DIRECT_MSG_REQ has been available
> > since FF-A specification v1.0.
> > 
> > Any feedback or alternative suggestions would be appreciated!
> > 
> > Link: https://lore.kernel.org/all/20260422162449.1814615-1-yeoreum.yun@arm.com/ [0]
> > 
> > Yeoreum Yun (3):
> >   arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
> >   firmware: arm_ffa: initialise ff-a after finalising pKVM
> >     initialisation
> >   security: integrity: call load_uefi_certs() at late_initcall_sync
> > 
> >  arch/arm64/kvm/arm.c                          |   8 +-
> >  arch/arm64/kvm/pkvm.c                         |  15 ++-
> >  drivers/firmware/arm_ffa/bus.c                | 125 +++++++++++++++++-
> >  drivers/firmware/arm_ffa/common.h             |  13 +-
> >  drivers/firmware/arm_ffa/driver.c             |  21 ++-
> >  drivers/firmware/arm_ffa/smccc.c              |   2 +-
> >  security/integrity/platform_certs/load_uefi.c |   2 +-
> >  7 files changed, 166 insertions(+), 20 deletions(-)
> > 
> > 
> > base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> 

-- 
Sincerely,
Yeoreum Yun

Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Yeoreum Yun]

> Hi Ben,
> 
> > Hi Levi,
> > 
> > On 5/5/26 10:54, Yeoreum Yun wrote:
> > > This patch is split out from the patchset [0] --
> > > fix FF-A call failure with pKVM when the FF-A driver is built-in,
> > > specifically the IMA-related part.
> > > 
> > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > buffer information, leading to failures in FF-A calls.
> > > 
> > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > while ffa_init() runs at the device_initcall level.
> > > 
> > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > still be trapped even before finalise_pkvm() is invoked.
> > > As a result, this issue has not been observed.
> > > 
> > > However, relying on above stuff is fragile.
> > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > initialised only after pKVM initialisation has been fully finalised.
> > > 
> > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > when pKVM is enabled.
> > > 
> > > This patch is based on v7.1-rc2
> > > 
> > > Question:
> > > 
> > > FF-A initialisation can occur at late_initcall. Because it may be deferred,
> > > some FF-A requests cannot be serviced at that stage.
> > > A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> > > 
> > > Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> > > and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> > > may be deferred to late_initcall. In this case, load_uefi_certs()
> > > can fail if it is invoked before the FF-A driver is initialised
> > > via deferred_probe_initcall().
> > > 
> > > Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> > > seems not to have any problem since late_initcall and
> > > late_initcall_sync are both of do_basic_setup() and it's before loading
> > > init process. However, it is still unclear whether
> > > it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
> > 
> > The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
> > 
> > Section 13.2.2 says:
> > 
> > "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> > the version must happen before an invocation of any other FF-A ABI."
> > 
> > and a bit further down
> > 
> > "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
> > 
> > I would have thought that an SP would only go into the waiting state once the version negotiation is done.
> 
> I mean the negotiation between hypervisor and ff-a driver.
> actually the version negotiation is done with SPMC in
> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
> just choose the lower version between version requested from ff-a driver
> and negotiated version with hypervisor and SPMC.

Sorry. re-parse the word, not choose "re-negotiate" when
FF-A driver request lowever version.

> 
> So, the version negotiation is already done with SPMC
> but with FF-A driver with hypervisor is not yet.
> However, DIRECT_MSG_REQ has supported from v1.0 
> In this situation, is there any reason not to send DIRECT_REQ_MSG?

IOW, question is that some of ff-a request can be allowed
before version negotiation with FF-A driver but
using negotiated version via hyp_ffa_init() first or not.

[...]

Thanks.

-- 
Sincerely,
Yeoreum Yun

Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Ben Horgan]

Hi Levi,

On 5/5/26 12:16, Yeoreum Yun wrote:
>> Hi Ben,
>>
>>> Hi Levi,
>>>
>>> On 5/5/26 10:54, Yeoreum Yun wrote:
>>>> This patch is split out from the patchset [0] --
>>>> fix FF-A call failure with pKVM when the FF-A driver is built-in,
>>>> specifically the IMA-related part.
>>>>
>>>> When pKVM is enabled, the FF-A driver must be initialised after pKVM.
>>>> Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
>>>> buffer information, leading to failures in FF-A calls.
>>>>
>>>> Currently, pKVM initialisation completes at device_initcall_sync,
>>>> while ffa_init() runs at the device_initcall level.
>>>>
>>>> So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
>>>> still be trapped even before finalise_pkvm() is invoked.
>>>> As a result, this issue has not been observed.
>>>>
>>>> However, relying on above stuff is fragile.
>>>> Therefore, when pKVM is enabled, the FF-A infrastructure should be
>>>> initialised only after pKVM initialisation has been fully finalised.
>>>>
>>>> To achieve this, introduce an ffa_root_dev ("arm-ffa") and
>>>> a corresponding driver to defer initialisation of the FF-A infrastructure
>>>> until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
>>>> when pKVM is enabled.
>>>>
>>>> This patch is based on v7.1-rc2
>>>>
>>>> Question:
>>>>
>>>> FF-A initialisation can occur at late_initcall. Because it may be deferred,
>>>> some FF-A requests cannot be serviced at that stage.
>>>> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
>>>>
>>>> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
>>>> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
>>>> may be deferred to late_initcall. In this case, load_uefi_certs()
>>>> can fail if it is invoked before the FF-A driver is initialised
>>>> via deferred_probe_initcall().
>>>>
>>>> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
>>>> seems not to have any problem since late_initcall and
>>>> late_initcall_sync are both of do_basic_setup() and it's before loading
>>>> init process. However, it is still unclear whether
>>>> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
>>>
>>> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
>>>
>>> Section 13.2.2 says:
>>>
>>> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
>>> the version must happen before an invocation of any other FF-A ABI."
>>>
>>> and a bit further down
>>>
>>> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
>>>
>>> I would have thought that an SP would only go into the waiting state once the version negotiation is done.
>>
>> I mean the negotiation between hypervisor and ff-a driver.
>> actually the version negotiation is done with SPMC in
>> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
>> just choose the lower version between version requested from ff-a driver
>> and negotiated version with hypervisor and SPMC.
> 
> Sorry. re-parse the word, not choose "re-negotiate" when
> FF-A driver request lowever version.
> 
>>
>> So, the version negotiation is already done with SPMC
>> but with FF-A driver with hypervisor is not yet.
>> However, DIRECT_MSG_REQ has supported from v1.0 
>> In this situation, is there any reason not to send DIRECT_REQ_MSG?
> 
> IOW, question is that some of ff-a request can be allowed
> before version negotiation with FF-A driver but
> using negotiated version via hyp_ffa_init() first or not.

I don't think so. Isn't it more a continuation of the negotiation rather than a re-negotiation?

Thanks,

Ben

> 
> [...]
> 
> Thanks.
> 

Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM

[Yeoreum Yun]

> Hi Levi,
> 
> On 5/5/26 12:16, Yeoreum Yun wrote:
> >> Hi Ben,
> >>
> >>> Hi Levi,
> >>>
> >>> On 5/5/26 10:54, Yeoreum Yun wrote:
> >>>> This patch is split out from the patchset [0] --
> >>>> fix FF-A call failure with pKVM when the FF-A driver is built-in,
> >>>> specifically the IMA-related part.
> >>>>
> >>>> When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> >>>> Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> >>>> buffer information, leading to failures in FF-A calls.
> >>>>
> >>>> Currently, pKVM initialisation completes at device_initcall_sync,
> >>>> while ffa_init() runs at the device_initcall level.
> >>>>
> >>>> So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> >>>> still be trapped even before finalise_pkvm() is invoked.
> >>>> As a result, this issue has not been observed.
> >>>>
> >>>> However, relying on above stuff is fragile.
> >>>> Therefore, when pKVM is enabled, the FF-A infrastructure should be
> >>>> initialised only after pKVM initialisation has been fully finalised.
> >>>>
> >>>> To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> >>>> a corresponding driver to defer initialisation of the FF-A infrastructure
> >>>> until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> >>>> when pKVM is enabled.
> >>>>
> >>>> This patch is based on v7.1-rc2
> >>>>
> >>>> Question:
> >>>>
> >>>> FF-A initialisation can occur at late_initcall. Because it may be deferred,
> >>>> some FF-A requests cannot be serviced at that stage.
> >>>> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> >>>>
> >>>> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> >>>> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> >>>> may be deferred to late_initcall. In this case, load_uefi_certs()
> >>>> can fail if it is invoked before the FF-A driver is initialised
> >>>> via deferred_probe_initcall().
> >>>>
> >>>> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> >>>> seems not to have any problem since late_initcall and
> >>>> late_initcall_sync are both of do_basic_setup() and it's before loading
> >>>> init process. However, it is still unclear whether
> >>>> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
> >>>
> >>> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
> >>>
> >>> Section 13.2.2 says:
> >>>
> >>> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> >>> the version must happen before an invocation of any other FF-A ABI."
> >>>
> >>> and a bit further down
> >>>
> >>> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
> >>>
> >>> I would have thought that an SP would only go into the waiting state once the version negotiation is done.
> >>
> >> I mean the negotiation between hypervisor and ff-a driver.
> >> actually the version negotiation is done with SPMC in
> >> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
> >> just choose the lower version between version requested from ff-a driver
> >> and negotiated version with hypervisor and SPMC.
> > 
> > Sorry. re-parse the word, not choose "re-negotiate" when
> > FF-A driver request lowever version.
> > 
> >>
> >> So, the version negotiation is already done with SPMC
> >> but with FF-A driver with hypervisor is not yet.
> >> However, DIRECT_MSG_REQ has supported from v1.0 
> >> In this situation, is there any reason not to send DIRECT_REQ_MSG?
> > 
> > IOW, question is that some of ff-a request can be allowed
> > before version negotiation with FF-A driver but
> > using negotiated version via hyp_ffa_init() first or not.
> 
> I don't think so. Isn't it more a continuation of the negotiation rather than a re-negotiation?

Might be. However, in the case I mentioned, I’m asking because
it’s somewhat unusual in that the FF-A request occurs without an “FF-A driver.”

If the FF-A request goes through the FF-A driver, then as you said,
it can reasonably be considered a continuation of the negotiation.
But in this case, I was wondering whether it would be acceptable to
introduce additional exception handling for situations
where an FF-A request occurs without the FF-A driver.

From that perspective, even if the FF-A request does not go through
the FF-A driver, it would ultimately still have to wait until
the FF-A driver initialization is complete.

So my question was whether certain operations could be handled
as exceptions in such cases.

Thanks.

-- 
Sincerely,
Yeoreum Yun