2023-09-29 15:14:24

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 00/17] firmware: arm_ffa: Add FF-A v1.1 support(notification + new memory descriptor format)

The series adds initial support for the notifications and memory transaction
descriptor changes added in FF-A v1.1 specification.

The notification mechanism enables a requester/sender endpoint to notify
a service provider/receiver endpoint about an event with non-blocking
semantics.

A notification is akin to the doorbell between two endpoints in a
communication protocol that is based upon the doorbell/mailbox mechanism.

The framework is responsible for the delivery of the notification from the
sender to the receiver without blocking the sender. The receiver endpoint
relies on the OS scheduler for allocation of CPU cycles to handle a
notification.

OS is referred as the receiver’s scheduler in the context of notifications.
The framework is responsible for informing the receiver’s scheduler that
the receiver must be run since it has a pending notification.

The series also includes support for the new format of memory transaction
descriptors.

Signed-off-by: Sudeep Holla <[email protected]>
---
Changes in v2:
- Added a fix for MEMORY LEND operation
- Upgraded the driver version
- Added support for the new format of memory transaction descriptors
- Remove unnecessary partition ID information in the notification
callbacks
- Fixed setting up drv_info->sched_recv_irq before enabling the SGIs
- Added missing resetting of bitmap_created in notifications_cleanup()
- Added some comments about GICv3 and SGI assumption
- Removed partition ID from the notification hash table entries as
they are redundant/incorrect. Added the notification type instead
(SP/VM/Framework)
- Link to v1: https://lore.kernel.org/all/[email protected]/

Changes in v3:
- Fixed ffa_mem_desc_offset() to not use possibly unpopulated structure members
- Fixed the parameter of handle_notif_callbacks(), must be notification type
instead of the partition ID.
- Fetch only secure partitions and SPM framework bitmaps until we add support
to this driver run in other than NS physical instance.
- Swapped back PACK_TARGET_INFO() arguments which I swapped in v2 with some
confusion during the review.
- Link to v2: https://lore.kernel.org/r/[email protected]

---
Sudeep Holla (17):
firmware: arm_ffa: Update the FF-A command list with v1.1 additions
firmware: arm_ffa: Implement notification bitmap create and destroy interfaces
firmware: arm_ffa: Implement the notification bind and unbind interface
firmware: arm_ffa: Implement the FFA_RUN interface
firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interface
firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interface
firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface
firmware: arm_ffa: Initial support for scheduler receiver interrupt
firmware: arm_ffa: Add schedule receiver callback mechanism
firmware: arm_ffa: Add interfaces to request notification callbacks
firmware: arm_ffa: Add interface to send a notification to a given partition
firmware: arm_ffa: Add notification handling mechanism
firmware: arm_ffa: Simplify the computation of transmit and fragment length
KVM: arm64: FFA: Remove access of endpoint memory access descriptor array
firmware: arm_ffa: Switch to using ffa_mem_desc_offset() accessor
firmware: arm_ffa: Update memory descriptor to support v1.1 format
firmware: arm_ffa: Upgrade the driver version to v1.1

arch/arm64/kvm/hyp/nvhe/ffa.c | 8 +-
drivers/firmware/arm_ffa/driver.c | 757 +++++++++++++++++++++++++++++++++++++-
include/linux/arm_ffa.h | 78 +++-
3 files changed, 818 insertions(+), 25 deletions(-)
---
base-commit: 2a4ec21976317b1ce8c5cd3e4fcd9e5d769c8fc4
change-id: 20230803-ffa_v1-1_notif-e11bc9459962

Best regards,
--
Regards,
Sudeep


2023-09-29 15:14:29

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 10/17] firmware: arm_ffa: Add interfaces to request notification callbacks

Add interface to the FFA driver to allow for client drivers to request
and relinquish a notification as well as provide a callback for the
notification.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 145 ++++++++++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 5 ++
2 files changed, 150 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 64f9c9e713d1..55707a5d333d 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -27,11 +27,13 @@
#include <linux/bitfield.h>
#include <linux/cpuhotplug.h>
#include <linux/device.h>
+#include <linux/hashtable.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mm.h>
+#include <linux/mutex.h>
#include <linux/of_irq.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
@@ -57,6 +59,8 @@
*/
#define RXTX_BUFFER_SIZE SZ_4K

+#define FFA_MAX_NOTIFICATIONS 64
+
static ffa_fn *invoke_ffa_fn;

static const int ffa_linux_errmap[] = {
@@ -103,6 +107,8 @@ struct ffa_drv_info {
bool info_get_64b;
struct xarray partition_info;
unsigned int partition_count;
+ DECLARE_HASHTABLE(notifier_hash, ilog2(FFA_MAX_NOTIFICATIONS));
+ struct mutex notify_lock; /* lock to protect notifier hashtable */
};

static struct ffa_drv_info *drv_info;
@@ -627,6 +633,8 @@ static int ffa_notification_bitmap_destroy(void)
#define MAX_IDS_64 20
#define MAX_IDS_32 10

+#define PER_VCPU_NOTIFICATION_FLAG BIT(0)
+
static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
u32 flags, bool is_bind)
{
@@ -871,6 +879,21 @@ static int ffa_memory_lend(struct ffa_mem_ops_args *args)
return ffa_memory_ops(FFA_MEM_LEND, args);
}

+#define FFA_SECURE_PARTITION_ID_FLAG BIT(15)
+
+enum notify_type {
+ NON_SECURE_VM,
+ SECURE_PARTITION,
+ FRAMEWORK,
+};
+
+struct notifier_cb_info {
+ struct hlist_node hnode;
+ ffa_notifier_cb cb;
+ void *cb_data;
+ enum notify_type type;
+};
+
static int ffa_sched_recv_cb_update(u16 part_id, ffa_sched_recv_cb callback,
void *cb_data, bool is_registration)
{
@@ -904,6 +927,123 @@ static int ffa_sched_recv_cb_unregister(struct ffa_device *dev)
return ffa_sched_recv_cb_update(dev->vm_id, NULL, NULL, false);
}

+static int ffa_notification_bind(u16 dst_id, u64 bitmap, u32 flags)
+{
+ return ffa_notification_bind_common(dst_id, bitmap, flags, true);
+}
+
+static int ffa_notification_unbind(u16 dst_id, u64 bitmap)
+{
+ return ffa_notification_bind_common(dst_id, bitmap, 0, false);
+}
+
+/* Should be called while the notify_lock is taken */
+static struct notifier_cb_info *
+notifier_hash_node_get(u16 notify_id, enum notify_type type)
+{
+ struct notifier_cb_info *node;
+
+ hash_for_each_possible(drv_info->notifier_hash, node, hnode, notify_id)
+ if (type == node->type)
+ return node;
+
+ return NULL;
+}
+
+static int
+update_notifier_cb(int notify_id, enum notify_type type, ffa_notifier_cb cb,
+ void *cb_data, bool is_registration)
+{
+ struct notifier_cb_info *cb_info = NULL;
+ bool cb_found;
+
+ cb_info = notifier_hash_node_get(notify_id, type);
+ cb_found = !!cb_info;
+
+ if (!(is_registration ^ cb_found))
+ return -EINVAL;
+
+ if (is_registration) {
+ cb_info = kzalloc(sizeof(*cb_info), GFP_KERNEL);
+ if (!cb_info)
+ return -ENOMEM;
+
+ cb_info->type = type;
+ cb_info->cb = cb;
+ cb_info->cb_data = cb_data;
+
+ hash_add(drv_info->notifier_hash, &cb_info->hnode, notify_id);
+ } else {
+ hash_del(&cb_info->hnode);
+ }
+
+ return 0;
+}
+
+static enum notify_type ffa_notify_type_get(u16 vm_id)
+{
+ if (vm_id & FFA_SECURE_PARTITION_ID_FLAG)
+ return SECURE_PARTITION;
+ else
+ return NON_SECURE_VM;
+}
+
+static int ffa_notify_relinquish(struct ffa_device *dev, int notify_id)
+{
+ int rc;
+ enum notify_type type = ffa_notify_type_get(dev->vm_id);
+
+ if (notify_id >= FFA_MAX_NOTIFICATIONS)
+ return -EINVAL;
+
+ mutex_lock(&drv_info->notify_lock);
+
+ rc = update_notifier_cb(notify_id, type, NULL, NULL, false);
+ if (rc) {
+ pr_err("Could not unregister notifcation callback\n");
+ mutex_unlock(&drv_info->notify_lock);
+ return rc;
+ }
+
+ rc = ffa_notification_unbind(dev->vm_id, BIT(notify_id));
+
+ mutex_unlock(&drv_info->notify_lock);
+
+ return rc;
+}
+
+static int ffa_notify_request(struct ffa_device *dev, bool is_per_vcpu,
+ ffa_notifier_cb cb, void *cb_data, int notify_id)
+{
+ int rc;
+ u32 flags = 0;
+ enum notify_type type = ffa_notify_type_get(dev->vm_id);
+
+ if (notify_id >= FFA_MAX_NOTIFICATIONS)
+ return -EINVAL;
+
+ mutex_lock(&drv_info->notify_lock);
+
+ if (is_per_vcpu)
+ flags = PER_VCPU_NOTIFICATION_FLAG;
+
+ rc = ffa_notification_bind(dev->vm_id, BIT(notify_id), flags);
+ if (rc) {
+ mutex_unlock(&drv_info->notify_lock);
+ return rc;
+ }
+
+ rc = update_notifier_cb(notify_id, type, cb, cb_data, true);
+ if (rc) {
+ pr_err("Failed to register callback for %d - %d\n",
+ notify_id, rc);
+ ffa_notification_unbind(dev->vm_id, BIT(notify_id));
+ }
+ mutex_unlock(&drv_info->notify_lock);
+
+ return rc;
+}
+
static const struct ffa_info_ops ffa_drv_info_ops = {
.api_version_get = ffa_api_version_get,
.partition_info_get = ffa_partition_info_get,
@@ -927,6 +1067,8 @@ static const struct ffa_cpu_ops ffa_drv_cpu_ops = {
static const struct ffa_notifier_ops ffa_drv_notifier_ops = {
.sched_recv_cb_register = ffa_sched_recv_cb_register,
.sched_recv_cb_unregister = ffa_sched_recv_cb_unregister,
+ .notify_request = ffa_notify_request,
+ .notify_relinquish = ffa_notify_relinquish,
};

static const struct ffa_ops ffa_drv_ops = {
@@ -1202,6 +1344,9 @@ static int ffa_notifications_setup(void)
if (ret)
goto cleanup;

+ hash_init(drv_info->notifier_hash);
+ mutex_init(&drv_info->notify_lock);
+
return 0;
cleanup:
ffa_notifications_cleanup();
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index f9cf6114ef82..fb6f388a3737 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -392,10 +392,15 @@ struct ffa_cpu_ops {
};

typedef void (*ffa_sched_recv_cb)(u16 vcpu, bool is_per_vcpu, void *cb_data);
+typedef void (*ffa_notifier_cb)(int notify_id, void *cb_data);
+
struct ffa_notifier_ops {
int (*sched_recv_cb_register)(struct ffa_device *dev,
ffa_sched_recv_cb cb, void *cb_data);
int (*sched_recv_cb_unregister)(struct ffa_device *dev);
+ int (*notify_request)(struct ffa_device *dev, bool per_vcpu,
+ ffa_notifier_cb cb, void *cb_data, int notify_id);
+ int (*notify_relinquish)(struct ffa_device *dev, int notify_id);
};

struct ffa_ops {

--
2.42.0

2023-09-29 15:20:56

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 17/17] firmware: arm_ffa: Upgrade the driver version to v1.1

With quite a few v1.1 features supported, we can bump the driver version
to v1.1 now.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 0168e69c495d..e9c6282d750c 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -43,7 +43,7 @@

#include "common.h"

-#define FFA_DRIVER_VERSION FFA_VERSION_1_0
+#define FFA_DRIVER_VERSION FFA_VERSION_1_1
#define FFA_MIN_VERSION FFA_VERSION_1_0

#define SENDER_ID_MASK GENMASK(31, 16)

--
2.42.0

2023-09-29 15:21:03

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 07/17] firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface

The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface
to retrieve the list of endpoints that have pending notifications and
must be run. A notification could be signaled by a sender in the secure
world to a VM. The Hypervisor needs to determine which VM and vCPU
(in case a per-vCPU notification is signaled) has a pending notification
in this scenario. It must obtain this information through an invocation
of the FFA_NOTIFICATION_INFO_GET.

Add the implementation of the NOTIFICATION_INFO_GET interface
and prepare to use this to handle the schedule receiver interrupt.
Implementation of handling notifications will be added later.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 70 +++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 02eedb7bc171..dfeeb751bebe 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -602,6 +602,13 @@ static int ffa_notification_bitmap_destroy(void)
(FIELD_PREP(RECEIVER_VCPU_MASK, (vcpu_r)) | \
FIELD_PREP(RECEIVER_ID_MASK, (r)))

+#define NOTIFICATION_INFO_GET_MORE_PEND_MASK BIT(0)
+#define NOTIFICATION_INFO_GET_ID_COUNT GENMASK(11, 7)
+#define ID_LIST_MASK_64 GENMASK(51, 12)
+#define ID_LIST_MASK_32 GENMASK(31, 12)
+#define MAX_IDS_64 20
+#define MAX_IDS_32 10
+
static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
u32 flags, bool is_bind)
{
@@ -673,6 +680,69 @@ static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
return 0;
}

+static void __do_sched_recv_cb(u16 partition_id, u16 vcpu, bool is_per_vcpu)
+{
+ pr_err("Callback for partition 0x%x failed.\n", partition_id);
+}
+
+static void ffa_notification_info_get(bool is_64b)
+{
+ int idx, list, max_ids, lists_cnt, ids_processed, ids_count[MAX_IDS_64];
+ ffa_value_t ret;
+ u64 id_list;
+
+ do {
+ invoke_ffa_fn((ffa_value_t){
+ .a0 = FFA_FN_NATIVE(NOTIFICATION_INFO_GET),
+ }, &ret);
+
+ if (ret.a0 != FFA_FN_NATIVE(SUCCESS)) {
+ if (ret.a2 != FFA_RET_NO_DATA)
+ pr_err("Notification Info fetch failed: 0x%lx (0x%lx)",
+ ret.a0, ret.a2);
+ return;
+ }
+
+ ids_processed = 0;
+ lists_cnt = FIELD_GET(NOTIFICATION_INFO_GET_ID_COUNT, ret.a2);
+ if (is_64b) {
+ max_ids = MAX_IDS_64;
+ id_list = FIELD_GET(ID_LIST_MASK_64, ret.a2);
+ } else {
+ max_ids = MAX_IDS_32;
+ id_list = FIELD_GET(ID_LIST_MASK_32, ret.a2);
+ }
+
+ for (idx = 0; idx < lists_cnt; idx++, id_list >>= 2)
+ ids_count[idx] = (id_list & 0x3) + 1;
+
+ /* Process IDs */
+ for (list = 0; list < lists_cnt; list++) {
+ u16 vcpu_id, part_id, *packed_id_list = (u16 *)&ret.a3;
+
+ if (ids_processed >= max_ids - 1)
+ break;
+
+ part_id = packed_id_list[++ids_processed];
+
+ if (!ids_count[list]) { /* Global Notification */
+ __do_sched_recv_cb(part_id, 0, false);
+ continue;
+ }
+
+ /* Per vCPU Notification */
+ for (idx = 0; idx < ids_count[list]; idx++) {
+ if (ids_processed >= max_ids - 1)
+ break;
+
+ vcpu_id = packed_id_list[++ids_processed];
+
+ __do_sched_recv_cb(part_id, vcpu_id, true);
+ }
+ }
+ } while (ret.a2 & NOTIFICATION_INFO_GET_MORE_PEND_MASK);
+}
+
static int ffa_run(struct ffa_device *dev, u16 vcpu)
{
ffa_value_t ret;

--
2.42.0

2023-09-29 15:21:07

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 09/17] firmware: arm_ffa: Add schedule receiver callback mechanism

Enable client drivers to register a callback function that will be
called when one or more notifications are pending for a target
partition as part of schedule receiver interrupt handling.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 103 ++++++++++++++++++++++++++++++++++++--
include/linux/arm_ffa.h | 8 +++
2 files changed, 108 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index a0c80eff04c4..64f9c9e713d1 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -37,6 +37,7 @@
#include <linux/slab.h>
#include <linux/smp.h>
#include <linux/uuid.h>
+#include <linux/xarray.h>

#include "common.h"

@@ -100,6 +101,8 @@ struct ffa_drv_info {
struct workqueue_struct *notif_pcpu_wq;
struct work_struct irq_work;
bool info_get_64b;
+ struct xarray partition_info;
+ unsigned int partition_count;
};

static struct ffa_drv_info *drv_info;
@@ -695,9 +698,26 @@ static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
return 0;
}

-static void __do_sched_recv_cb(u16 partition_id, u16 vcpu, bool is_per_vcpu)
+struct ffa_dev_part_info {
+ ffa_sched_recv_cb callback;
+ void *cb_data;
+ rwlock_t rw_lock;
+};
+
+static void __do_sched_recv_cb(u16 part_id, u16 vcpu, bool is_per_vcpu)
{
- pr_err("Callback for partition 0x%x failed.\n", partition_id);
+ struct ffa_dev_part_info *partition;
+ ffa_sched_recv_cb callback;
+ void *cb_data;
+
+ partition = xa_load(&drv_info->partition_info, part_id);
+ read_lock(&partition->rw_lock);
+ callback = partition->callback;
+ cb_data = partition->cb_data;
+ read_unlock(&partition->rw_lock);
+
+ if (callback)
+ callback(vcpu, is_per_vcpu, cb_data);
}

static void ffa_notification_info_get(bool is_64b)
@@ -851,6 +871,39 @@ static int ffa_memory_lend(struct ffa_mem_ops_args *args)
return ffa_memory_ops(FFA_MEM_LEND, args);
}

+static int ffa_sched_recv_cb_update(u16 part_id, ffa_sched_recv_cb callback,
+ void *cb_data, bool is_registration)
+{
+ struct ffa_dev_part_info *partition;
+ bool cb_valid;
+
+ partition = xa_load(&drv_info->partition_info, part_id);
+ write_lock(&partition->rw_lock);
+
+ cb_valid = !!partition->callback;
+ if (!(is_registration ^ cb_valid)) {
+ write_unlock(&partition->rw_lock);
+ return -EINVAL;
+ }
+
+ partition->callback = callback;
+ partition->cb_data = cb_data;
+
+ write_unlock(&partition->rw_lock);
+ return 0;
+}
+
+static int ffa_sched_recv_cb_register(struct ffa_device *dev,
+ ffa_sched_recv_cb cb, void *cb_data)
+{
+ return ffa_sched_recv_cb_update(dev->vm_id, cb, cb_data, true);
+}
+
+static int ffa_sched_recv_cb_unregister(struct ffa_device *dev)
+{
+ return ffa_sched_recv_cb_update(dev->vm_id, NULL, NULL, false);
+}
+
static const struct ffa_info_ops ffa_drv_info_ops = {
.api_version_get = ffa_api_version_get,
.partition_info_get = ffa_partition_info_get,
@@ -871,11 +924,17 @@ static const struct ffa_cpu_ops ffa_drv_cpu_ops = {
.run = ffa_run,
};

+static const struct ffa_notifier_ops ffa_drv_notifier_ops = {
+ .sched_recv_cb_register = ffa_sched_recv_cb_register,
+ .sched_recv_cb_unregister = ffa_sched_recv_cb_unregister,
+};
+
static const struct ffa_ops ffa_drv_ops = {
.info_ops = &ffa_drv_info_ops,
.msg_ops = &ffa_drv_msg_ops,
.mem_ops = &ffa_drv_mem_ops,
.cpu_ops = &ffa_drv_cpu_ops,
+ .notifier_ops = &ffa_drv_notifier_ops,
};

void ffa_device_match_uuid(struct ffa_device *ffa_dev, const uuid_t *uuid)
@@ -906,6 +965,7 @@ static void ffa_setup_partitions(void)
int count, idx;
uuid_t uuid;
struct ffa_device *ffa_dev;
+ struct ffa_dev_part_info *info;
struct ffa_partition_info *pbuf, *tpbuf;

count = ffa_partition_probe(&uuid_null, &pbuf);
@@ -914,6 +974,7 @@ static void ffa_setup_partitions(void)
return;
}

+ xa_init(&drv_info->partition_info);
for (idx = 0, tpbuf = pbuf; idx < count; idx++, tpbuf++) {
import_uuid(&uuid, (u8 *)tpbuf->uuid);

@@ -933,10 +994,42 @@ static void ffa_setup_partitions(void)
if (drv_info->version > FFA_VERSION_1_0 &&
!(tpbuf->properties & FFA_PARTITION_AARCH64_EXEC))
_ffa_mode_32bit_set(ffa_dev);
+
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ if (!info) {
+ ffa_device_unregister(ffa_dev);
+ continue;
+ }
+ xa_store(&drv_info->partition_info, tpbuf->id, info, GFP_KERNEL);
}
+ drv_info->partition_count = count;
+
kfree(pbuf);
}

+static void ffa_partitions_cleanup(void)
+{
+ struct ffa_dev_part_info **info;
+ int idx, count = drv_info->partition_count;
+
+ if (!count)
+ return;
+
+ info = kcalloc(count, sizeof(**info), GFP_KERNEL);
+ if (!info)
+ return;
+
+ xa_extract(&drv_info->partition_info, (void **)info, 0, VM_ID_MASK,
+ count, XA_PRESENT);
+
+ for (idx = 0; idx < count; idx++)
+ kfree(info[idx]);
+ kfree(info);
+
+ drv_info->partition_count = 0;
+ xa_destroy(&drv_info->partition_info);
+}
+
/* FFA FEATURE IDs */
#define FFA_FEAT_NOTIFICATION_PENDING_INT (1)
#define FFA_FEAT_SCHEDULE_RECEIVER_INT (2)
@@ -1172,9 +1265,11 @@ static int __init ffa_init(void)

ret = ffa_notifications_setup();
if (ret)
- goto free_pages;
+ goto partitions_cleanup;

return 0;
+partitions_cleanup:
+ ffa_partitions_cleanup();
free_pages:
if (drv_info->tx_buffer)
free_pages_exact(drv_info->tx_buffer, RXTX_BUFFER_SIZE);
@@ -1190,9 +1285,11 @@ subsys_initcall(ffa_init);
static void __exit ffa_exit(void)
{
ffa_notifications_cleanup();
+ ffa_partitions_cleanup();
ffa_rxtx_unmap(drv_info->vm_id);
free_pages_exact(drv_info->tx_buffer, RXTX_BUFFER_SIZE);
free_pages_exact(drv_info->rx_buffer, RXTX_BUFFER_SIZE);
+ xa_destroy(&drv_info->partition_info);
kfree(drv_info);
arm_ffa_bus_exit();
}
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 12fd134bf670..f9cf6114ef82 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -391,11 +391,19 @@ struct ffa_cpu_ops {
int (*run)(struct ffa_device *dev, u16 vcpu);
};

+typedef void (*ffa_sched_recv_cb)(u16 vcpu, bool is_per_vcpu, void *cb_data);
+struct ffa_notifier_ops {
+ int (*sched_recv_cb_register)(struct ffa_device *dev,
+ ffa_sched_recv_cb cb, void *cb_data);
+ int (*sched_recv_cb_unregister)(struct ffa_device *dev);
+};
+
struct ffa_ops {
const struct ffa_info_ops *info_ops;
const struct ffa_msg_ops *msg_ops;
const struct ffa_mem_ops *mem_ops;
const struct ffa_cpu_ops *cpu_ops;
+ const struct ffa_notifier_ops *notifier_ops;
};

#endif /* _LINUX_ARM_FFA_H */

--
2.42.0

2023-09-29 15:28:16

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 13/17] firmware: arm_ffa: Simplify the computation of transmit and fragment length

The computation of endpoint memory access descriptor's composite memory
region descriptor offset is using COMPOSITE_CONSTITUENTS_OFFSET which is
unnecessary complicated. Composite memory region descriptor always follow
the endpoint memory access descriptor array and hence it is computed
accordingly. COMPOSITE_CONSTITUENTS_OFFSET is useless and wrong for any
input other than endpoint memory access descriptor count.

Let us drop the usage of COMPOSITE_CONSTITUENTS_OFFSET to simplify the
computation of total transmit and fragment length in the memory
transactions.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 14 ++++++++------
include/linux/arm_ffa.h | 2 --
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 28bf345862d9..d9ff3ec4f1eb 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -443,23 +443,25 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
{
int rc = 0;
bool first = true;
+ u32 composite_offset;
phys_addr_t addr = 0;
+ struct ffa_mem_region *mem_region = buffer;
struct ffa_composite_mem_region *composite;
struct ffa_mem_region_addr_range *constituents;
struct ffa_mem_region_attributes *ep_mem_access;
- struct ffa_mem_region *mem_region = buffer;
u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg);

mem_region->tag = args->tag;
mem_region->flags = args->flags;
mem_region->sender_id = drv_info->vm_id;
mem_region->attributes = ffa_memory_attributes_get(func_id);
- ep_mem_access = &mem_region->ep_mem_access[0];
+ ep_mem_access = buffer + COMPOSITE_OFFSET(0);
+ composite_offset = COMPOSITE_OFFSET(args->nattrs);

for (idx = 0; idx < args->nattrs; idx++, ep_mem_access++) {
ep_mem_access->receiver = args->attrs[idx].receiver;
ep_mem_access->attrs = args->attrs[idx].attrs;
- ep_mem_access->composite_off = COMPOSITE_OFFSET(args->nattrs);
+ ep_mem_access->composite_off = composite_offset;
ep_mem_access->flag = 0;
ep_mem_access->reserved = 0;
}
@@ -468,13 +470,13 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
mem_region->reserved_1 = 0;
mem_region->ep_count = args->nattrs;

- composite = buffer + COMPOSITE_OFFSET(args->nattrs);
+ composite = buffer + composite_offset;
composite->total_pg_cnt = ffa_get_num_pages_sg(args->sg);
composite->addr_range_cnt = num_entries;
composite->reserved = 0;

- length = COMPOSITE_CONSTITUENTS_OFFSET(args->nattrs, num_entries);
- frag_len = COMPOSITE_CONSTITUENTS_OFFSET(args->nattrs, 0);
+ length = composite_offset + CONSTITUENTS_OFFSET(num_entries);
+ frag_len = composite_offset + CONSTITUENTS_OFFSET(0);
if (frag_len > max_fragsize)
return -ENXIO;

diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index f6df81f14b6d..748d0a83a4bc 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -356,8 +356,6 @@ struct ffa_mem_region {
(offsetof(struct ffa_mem_region, ep_mem_access[x]))
#define CONSTITUENTS_OFFSET(x) \
(offsetof(struct ffa_composite_mem_region, constituents[x]))
-#define COMPOSITE_CONSTITUENTS_OFFSET(x, y) \
- (COMPOSITE_OFFSET(x) + CONSTITUENTS_OFFSET(y))

struct ffa_mem_ops_args {
bool use_txbuf;

--
2.42.0

2023-09-29 15:41:58

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 16/17] firmware: arm_ffa: Update memory descriptor to support v1.1 format

Update memory transaction descriptor structure to accommodate couple of
new entries in v1.1 which were previously marked reserved and MBZ(must
be zero).

It also removes the flexible array member ep_mem_access in the memory
transaction descriptor structure as it need not be at fixed offset.
Also update ffa_mem_desc_offset() accessor to handle both old and new
formats of memory transaction descriptors.

The updates ffa_mem_region structure aligns with new format in v1.1 and
hence the driver/user must take care not to use members beyond and
including ep_mem_offset when using the old format.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 11 ++++++++---
include/linux/arm_ffa.h | 32 +++++++++++++++++++++-----------
2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index ef7011c86d60..0168e69c495d 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -424,7 +424,7 @@ static u32 ffa_get_num_pages_sg(struct scatterlist *sg)
return num_pages;
}

-static u8 ffa_memory_attributes_get(u32 func_id)
+static u16 ffa_memory_attributes_get(u32 func_id)
{
/*
* For the memory lend or donate operation, if the receiver is a PE or
@@ -467,9 +467,14 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
ep_mem_access->reserved = 0;
}
mem_region->handle = 0;
- mem_region->reserved_0 = 0;
- mem_region->reserved_1 = 0;
mem_region->ep_count = args->nattrs;
+ if (mdesc_v1) {
+ mem_region->ep_mem_size = 0;
+ } else {
+ mem_region->ep_mem_size = sizeof(*ep_mem_access);
+ mem_region->ep_mem_offset = sizeof(*mem_region);
+ memset(mem_region->reserved, 0, 12);
+ }

composite = buffer + composite_offset;
composite->total_pg_cnt = ffa_get_num_pages_sg(args->sg);
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 7be240e37f36..f3adba0ef6c6 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -298,8 +298,8 @@ struct ffa_mem_region {
#define FFA_MEM_NON_SHAREABLE (0)
#define FFA_MEM_OUTER_SHAREABLE (2)
#define FFA_MEM_INNER_SHAREABLE (3)
- u8 attributes;
- u8 reserved_0;
+ /* Memory region attributes, upper byte MBZ pre v1.1 */
+ u16 attributes;
/*
* Clear memory region contents after unmapping it from the sender and
* before mapping it for any receiver.
@@ -337,30 +337,40 @@ struct ffa_mem_region {
* memory region.
*/
u64 tag;
- u32 reserved_1;
+ /* Size of each endpoint memory access descriptor, MBZ pre v1.1 */
+ u32 ep_mem_size;
/*
* The number of `ffa_mem_region_attributes` entries included in this
* transaction.
*/
u32 ep_count;
/*
- * An array of endpoint memory access descriptors.
- * Each one specifies a memory region offset, an endpoint and the
- * attributes with which this memory region should be mapped in that
- * endpoint's page table.
+ * 16-byte aligned offset from the base address of this descriptor
+ * to the first element of the endpoint memory access descriptor array
+ * Valid only from v1.1
*/
- struct ffa_mem_region_attributes ep_mem_access[];
+ u32 ep_mem_offset;
+ /* MBZ, valid only from v1.1 */
+ u32 reserved[3];
};

-#define COMPOSITE_OFFSET(x) \
- (offsetof(struct ffa_mem_region, ep_mem_access[x]))
#define CONSTITUENTS_OFFSET(x) \
(offsetof(struct ffa_composite_mem_region, constituents[x]))

static inline u32
ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, bool mem_desc_v1)
{
- return COMPOSITE_OFFSET(0);
+ u32 offset = count * sizeof(struct ffa_mem_region_attributes);
+ /*
+ * Earlier to v1.1, the endpoint memory descriptor array started at
+ * offset 32(i.e. offset of ep_mem_offset itself)
+ */
+ if (mem_desc_v1)
+ offset += offsetof(struct ffa_mem_region, ep_mem_offset);
+ else
+ offset += sizeof(struct ffa_mem_region);
+
+ return offset;
}

struct ffa_mem_ops_args {

--
2.42.0

2023-09-29 15:42:00

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 04/17] firmware: arm_ffa: Implement the FFA_RUN interface

FFA_RUN is used by a scheduler to allocate CPU cycles to a target
endpoint execution context specified in the target information parameter.

If the endpoint execution context is in the waiting/blocked state, it
transitions to the running state.

Expose the ability to call FFA_RUN in order to give any partition in the
system cpu cycles to perform IMPDEF functionality.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 22 ++++++++++++++++++++++
include/linux/arm_ffa.h | 5 +++++
2 files changed, 27 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 26bf9c4e3b5f..b265063e76ea 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -616,6 +616,23 @@ static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
return 0;
}

+static int ffa_run(struct ffa_device *dev, u16 vcpu)
+{
+ ffa_value_t ret;
+ u32 target = dev->vm_id << 16 | vcpu;
+
+ invoke_ffa_fn((ffa_value_t){ .a0 = FFA_RUN, .a1 = target, }, &ret);
+
+ while (ret.a0 == FFA_INTERRUPT)
+ invoke_ffa_fn((ffa_value_t){ .a0 = FFA_RUN, .a1 = ret.a1, },
+ &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+
+ return 0;
+}
+
static void ffa_set_up_mem_ops_native_flag(void)
{
if (!ffa_features(FFA_FN_NATIVE(MEM_LEND), 0, NULL, NULL) ||
@@ -708,10 +725,15 @@ static const struct ffa_mem_ops ffa_drv_mem_ops = {
.memory_lend = ffa_memory_lend,
};

+static const struct ffa_cpu_ops ffa_drv_cpu_ops = {
+ .run = ffa_run,
+};
+
static const struct ffa_ops ffa_drv_ops = {
.info_ops = &ffa_drv_info_ops,
.msg_ops = &ffa_drv_msg_ops,
.mem_ops = &ffa_drv_mem_ops,
+ .cpu_ops = &ffa_drv_cpu_ops,
};

void ffa_device_match_uuid(struct ffa_device *ffa_dev, const uuid_t *uuid)
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 2ea1717a0825..12fd134bf670 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -387,10 +387,15 @@ struct ffa_mem_ops {
int (*memory_lend)(struct ffa_mem_ops_args *args);
};

+struct ffa_cpu_ops {
+ int (*run)(struct ffa_device *dev, u16 vcpu);
+};
+
struct ffa_ops {
const struct ffa_info_ops *info_ops;
const struct ffa_msg_ops *msg_ops;
const struct ffa_mem_ops *mem_ops;
+ const struct ffa_cpu_ops *cpu_ops;
};

#endif /* _LINUX_ARM_FFA_H */

--
2.42.0

2023-09-29 15:42:07

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

A receiver endpoint must bind a notification to any sender endpoint
before the latter can signal the notification to the former. The receiver
assigns one or more doorbells to a specific sender. Only the sender can
ring these doorbells.

A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
notifications to the sender. A receiver un-binds a notification from a
sender endpoint to stop the notification from being signaled. It uses
the FFA_NOTIFICATION_UNBIND interface to do this.

Allow the FF-A driver to be able to bind and unbind a given notification
ID to a specific partition ID. This will be used to register and
unregister notification callbacks from the FF-A client drivers.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index efa4e7fb15e3..26bf9c4e3b5f 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -587,6 +587,35 @@ static int ffa_notification_bitmap_destroy(void)
return 0;
}

+#define NOTIFICATION_LOW_MASK GENMASK(31, 0)
+#define NOTIFICATION_HIGH_MASK GENMASK(63, 32)
+#define NOTIFICATION_BITMAP_HIGH(x) \
+ ((u32)(FIELD_GET(NOTIFICATION_HIGH_MASK, (x))))
+#define NOTIFICATION_BITMAP_LOW(x) \
+ ((u32)(FIELD_GET(NOTIFICATION_LOW_MASK, (x))))
+
+static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
+ u32 flags, bool is_bind)
+{
+ ffa_value_t ret;
+ u32 func, src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);
+
+ func = is_bind ? FFA_NOTIFICATION_BIND : FFA_NOTIFICATION_UNBIND;
+
+ invoke_ffa_fn((ffa_value_t){
+ .a0 = func, .a1 = src_dst_ids, .a2 = flags,
+ .a3 = NOTIFICATION_BITMAP_LOW(bitmap),
+ .a4 = NOTIFICATION_BITMAP_HIGH(bitmap),
+ }, &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+ else if (ret.a0 != FFA_SUCCESS)
+ return -EINVAL;
+
+ return 0;
+}
+
static void ffa_set_up_mem_ops_native_flag(void)
{
if (!ffa_features(FFA_FN_NATIVE(MEM_LEND), 0, NULL, NULL) ||

--
2.42.0

2023-09-29 15:42:08

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 14/17] KVM: arm64: FFA: Remove access of endpoint memory access descriptor array

FF-A v1.1 removes the fixed location of endpoint memory access descriptor
array within the memory transaction descriptor structure. In preparation
to remove the ep_mem_access member from the ffa_mem_region structure,
provide the accessor to fetch the offset and use the same in FF-A proxy
implementation.

The accessor take the boolean argument that indicates if the memory access
descriptor versions is v1(old format) or not. Currently it is set true as
FF-A proxy supports only v1.0

Cc: Marc Zyngier <[email protected]>
Cc: Oliver Upton <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Quentin Perret <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 8 ++++++--
include/linux/arm_ffa.h | 6 ++++++
2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 6e4dba9eadef..5f956f53e6bf 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -423,6 +423,7 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
DECLARE_REG(u32, fraglen, ctxt, 2);
DECLARE_REG(u64, addr_mbz, ctxt, 3);
DECLARE_REG(u32, npages_mbz, ctxt, 4);
+ struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
struct ffa_mem_region *buf;
u32 offset, nr_ranges;
@@ -452,7 +453,8 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);

- offset = buf->ep_mem_access[0].composite_off;
+ ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
+ offset = ep_mem_access->composite_off;
if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out_unlock;
@@ -504,6 +506,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
DECLARE_REG(u32, handle_lo, ctxt, 1);
DECLARE_REG(u32, handle_hi, ctxt, 2);
DECLARE_REG(u32, flags, ctxt, 3);
+ struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
u32 offset, len, fraglen, fragoff;
struct ffa_mem_region *buf;
@@ -528,7 +531,8 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
len = res->a1;
fraglen = res->a2;

- offset = buf->ep_mem_access[0].composite_off;
+ ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
+ offset = ep_mem_access->composite_off;
/*
* We can trust the SPMD to get this right, but let's at least
* check that we end up with something that doesn't look _completely_
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 748d0a83a4bc..7be240e37f36 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -357,6 +357,12 @@ struct ffa_mem_region {
#define CONSTITUENTS_OFFSET(x) \
(offsetof(struct ffa_composite_mem_region, constituents[x]))

+static inline u32
+ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, bool mem_desc_v1)
+{
+ return COMPOSITE_OFFSET(0);
+}
+
struct ffa_mem_ops_args {
bool use_txbuf;
u32 nattrs;

--
2.42.0

2023-09-29 15:42:14

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 08/17] firmware: arm_ffa: Initial support for scheduler receiver interrupt

The Framework uses the schedule receiver interrupt to inform the
receiver’s scheduler that the receiver must be run to handle a pending
notification. A receiver’s scheduler can obtain the description of the
schedule receiver interrupt by invoking the FFA_FEATURES interface.

The delivery of the physical schedule receiver interrupt from the secure
state to the non-secure state depends upon the state of the interrupt
controller as configured by the hypervisor.

The schedule seceiver interrupt is assumed to be a SGI. The Arm GIC
specification defines 16 SGIs. It recommends that they are equally
divided between the non-secure and secure states. OS like Linux kernel
in the non-secure state typically do not have SGIs to spare. The usage
of SGIs in the secure state is however limited. It is more likely that
software in the Secure world does not use all the SGIs allocated to it.

It is recommended that the secure world software donates an unused SGI
to the normal world for use as the schedule receiver interrupt. This
implies that secure world software must configure the SGI in the GIC
as a non-secure interrupt before presenting it to the normal world.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 192 ++++++++++++++++++++++++++++++++++++--
1 file changed, 182 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index dfeeb751bebe..a0c80eff04c4 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -22,15 +22,20 @@
#define DRIVER_NAME "ARM FF-A"
#define pr_fmt(fmt) DRIVER_NAME ": " fmt

+#include <linux/acpi.h>
#include <linux/arm_ffa.h>
#include <linux/bitfield.h>
+#include <linux/cpuhotplug.h>
#include <linux/device.h>
+#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mm.h>
+#include <linux/of_irq.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
+#include <linux/smp.h>
#include <linux/uuid.h>

#include "common.h"
@@ -76,6 +81,10 @@ static inline int ffa_to_linux_errno(int errno)
return -EINVAL;
}

+struct ffa_pcpu_irq {
+ struct ffa_drv_info *info;
+};
+
struct ffa_drv_info {
u32 version;
u16 vm_id;
@@ -85,6 +94,12 @@ struct ffa_drv_info {
void *tx_buffer;
bool mem_ops_native;
bool bitmap_created;
+ unsigned int sched_recv_irq;
+ unsigned int cpuhp_state;
+ struct ffa_pcpu_irq __percpu *irq_pcpu;
+ struct workqueue_struct *notif_pcpu_wq;
+ struct work_struct irq_work;
+ bool info_get_64b;
};

static struct ffa_drv_info *drv_info;
@@ -922,9 +937,153 @@ static void ffa_setup_partitions(void)
kfree(pbuf);
}

+/* FFA FEATURE IDs */
+#define FFA_FEAT_NOTIFICATION_PENDING_INT (1)
+#define FFA_FEAT_SCHEDULE_RECEIVER_INT (2)
+#define FFA_FEAT_MANAGED_EXIT_INT (3)
+
+static irqreturn_t irq_handler(int irq, void *irq_data)
+{
+ struct ffa_pcpu_irq *pcpu = irq_data;
+ struct ffa_drv_info *info = pcpu->info;
+
+ queue_work(info->notif_pcpu_wq, &info->irq_work);
+
+ return IRQ_HANDLED;
+}
+
+static void ffa_sched_recv_irq_work_fn(struct work_struct *work)
+{
+ struct ffa_drv_info *info = container_of(work, struct ffa_drv_info,
+ irq_work);
+
+ ffa_notification_info_get(info->info_get_64b);
+}
+
+static int ffa_sched_recv_irq_map(void)
+{
+ int ret, irq, sr_intid;
+
+ /* The returned sr_intid is assumed to be SGI donated to NS world */
+ ret = ffa_features(FFA_FEAT_SCHEDULE_RECEIVER_INT, 0, &sr_intid, NULL);
+ if (ret < 0) {
+ if (ret != -EOPNOTSUPP)
+ pr_err("Failed to retrieve scheduler Rx interrupt\n");
+ return ret;
+ }
+
+ if (acpi_disabled) {
+ struct of_phandle_args oirq = {};
+ struct device_node *gic;
+
+ /* Only GICv3 supported currently with the device tree */
+ gic = of_find_compatible_node(NULL, NULL, "arm,gic-v3");
+ if (!gic)
+ return -ENXIO;
+
+ oirq.np = gic;
+ oirq.args_count = 1;
+ oirq.args[0] = sr_intid;
+ irq = irq_create_of_mapping(&oirq);
+ of_node_put(gic);
+#ifdef CONFIG_ACPI
+ } else {
+ irq = acpi_register_gsi(NULL, sr_intid, ACPI_EDGE_SENSITIVE,
+ ACPI_ACTIVE_HIGH);
+#endif
+ }
+
+ if (irq <= 0) {
+ pr_err("Failed to create IRQ mapping!\n");
+ return -ENODATA;
+ }
+
+ return irq;
+}
+
+static void ffa_sched_recv_irq_unmap(void)
+{
+ if (drv_info->sched_recv_irq)
+ irq_dispose_mapping(drv_info->sched_recv_irq);
+}
+
+static int ffa_cpuhp_pcpu_irq_enable(unsigned int cpu)
+{
+ enable_percpu_irq(drv_info->sched_recv_irq, IRQ_TYPE_NONE);
+ return 0;
+}
+
+static int ffa_cpuhp_pcpu_irq_disable(unsigned int cpu)
+{
+ disable_percpu_irq(drv_info->sched_recv_irq);
+ return 0;
+}
+
+static void ffa_uninit_pcpu_irq(void)
+{
+ if (drv_info->cpuhp_state)
+ cpuhp_remove_state(drv_info->cpuhp_state);
+
+ if (drv_info->notif_pcpu_wq)
+ destroy_workqueue(drv_info->notif_pcpu_wq);
+
+ if (drv_info->sched_recv_irq)
+ free_percpu_irq(drv_info->sched_recv_irq, drv_info->irq_pcpu);
+
+ if (drv_info->irq_pcpu)
+ free_percpu(drv_info->irq_pcpu);
+}
+
+static int ffa_init_pcpu_irq(unsigned int irq)
+{
+ struct ffa_pcpu_irq __percpu *irq_pcpu;
+ int ret, cpu;
+
+ irq_pcpu = alloc_percpu(struct ffa_pcpu_irq);
+ if (!irq_pcpu)
+ return -ENOMEM;
+
+ for_each_present_cpu(cpu)
+ per_cpu_ptr(irq_pcpu, cpu)->info = drv_info;
+
+ drv_info->irq_pcpu = irq_pcpu;
+
+ ret = request_percpu_irq(irq, irq_handler, "ARM-FFA", irq_pcpu);
+ if (ret) {
+ pr_err("Error registering notification IRQ %d: %d\n", irq, ret);
+ return ret;
+ }
+
+ INIT_WORK(&drv_info->irq_work, ffa_sched_recv_irq_work_fn);
+ drv_info->notif_pcpu_wq = create_workqueue("ffa_pcpu_irq_notification");
+ if (!drv_info->notif_pcpu_wq)
+ return -EINVAL;
+
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "ffa/pcpu-irq:starting",
+ ffa_cpuhp_pcpu_irq_enable,
+ ffa_cpuhp_pcpu_irq_disable);
+
+ if (ret < 0)
+ return ret;
+
+ drv_info->cpuhp_state = ret;
+ return 0;
+}
+
+static void ffa_notifications_cleanup(void)
+{
+ ffa_uninit_pcpu_irq();
+ ffa_sched_recv_irq_unmap();
+
+ if (drv_info->bitmap_created) {
+ ffa_notification_bitmap_destroy();
+ drv_info->bitmap_created = false;
+ }
+}
+
static int ffa_notifications_setup(void)
{
- int ret;
+ int ret, irq;

ret = ffa_features(FFA_NOTIFICATION_BITMAP_CREATE, 0, NULL, NULL);
if (!ret) {
@@ -936,15 +1095,24 @@ static int ffa_notifications_setup(void)
}
drv_info->bitmap_created = true;

- return 0;
-}
+ irq = ffa_sched_recv_irq_map();
+ if (irq <= 0)
+ goto cleanup;

-static void ffa_notifications_cleanup(void)
-{
- if (drv_info->bitmap_created) {
- ffa_notification_bitmap_destroy();
- drv_info->bitmap_created = false;
- }
+ if (FFA_FN_NATIVE(NOTIFICATION_INFO_GET) ==
+ FFA_FN64_NOTIFICATION_INFO_GET)
+ drv_info->info_get_64b = true;
+
+ drv_info->sched_recv_irq = irq;
+
+ ret = ffa_init_pcpu_irq(irq);
+ if (ret)
+ goto cleanup;
+
+ return 0;
+cleanup:
+ ffa_notifications_cleanup();
+ return ret;
}

static int __init ffa_init(void)
@@ -1002,7 +1170,11 @@ static int __init ffa_init(void)

ffa_set_up_mem_ops_native_flag();

- return ffa_notifications_setup();
+ ret = ffa_notifications_setup();
+ if (ret)
+ goto free_pages;
+
+ return 0;
free_pages:
if (drv_info->tx_buffer)
free_pages_exact(drv_info->tx_buffer, RXTX_BUFFER_SIZE);

--
2.42.0

2023-09-29 15:42:18

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 12/17] firmware: arm_ffa: Add notification handling mechanism

With all the necessary plumbing in place, let us add handling the
notifications as part of schedule receiver interrupt handler. In order
to do so, we need to just register scheduling callback on behalf of the
driver partition.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 65 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 94e39ee83278..28bf345862d9 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -103,6 +103,7 @@ struct ffa_drv_info {
unsigned int cpuhp_state;
struct ffa_pcpu_irq __percpu *irq_pcpu;
struct workqueue_struct *notif_pcpu_wq;
+ struct work_struct notif_pcpu_work;
struct work_struct irq_work;
bool info_get_64b;
struct xarray partition_info;
@@ -634,6 +635,10 @@ static int ffa_notification_bitmap_destroy(void)
#define MAX_IDS_32 10

#define PER_VCPU_NOTIFICATION_FLAG BIT(0)
+#define SECURE_PARTITION_BITMAP BIT(0)
+#define NON_SECURE_VM_BITMAP BIT(1)
+#define SPM_FRAMEWORK_BITMAP BIT(2)
+#define NS_HYP_FRAMEWORK_BITMAP BIT(3)

static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
u32 flags, bool is_bind)
@@ -1056,6 +1061,54 @@ static int ffa_notify_send(struct ffa_device *dev, int notify_id,
BIT(notify_id));
}

+static void handle_notif_callbacks(u64 bitmap, enum notify_type type)
+{
+ int notify_id;
+ struct notifier_cb_info *cb_info = NULL;
+
+ for (notify_id = 0; notify_id <= FFA_MAX_NOTIFICATIONS && bitmap;
+ notify_id++, bitmap >>= 1) {
+ if (!(bitmap & 1))
+ continue;
+
+ mutex_lock(&drv_info->notify_lock);
+ cb_info = notifier_hash_node_get(notify_id, type);
+ mutex_unlock(&drv_info->notify_lock);
+
+ if (cb_info && cb_info->cb)
+ cb_info->cb(notify_id, cb_info->cb_data);
+ }
+}
+
+static void notif_pcpu_irq_work_fn(struct work_struct *work)
+{
+ int rc;
+ struct ffa_notify_bitmaps bitmaps;
+
+ rc = ffa_notification_get(SECURE_PARTITION_BITMAP |
+ SPM_FRAMEWORK_BITMAP, &bitmaps);
+ if (rc) {
+ pr_err("Failed to retrieve notifications with %d!\n", rc);
+ return;
+ }
+
+ handle_notif_callbacks(bitmaps.vm_map, NON_SECURE_VM);
+ handle_notif_callbacks(bitmaps.sp_map, SECURE_PARTITION);
+ handle_notif_callbacks(bitmaps.arch_map, FRAMEWORK);
+}
+
+static void
+ffa_self_notif_handle(u16 vcpu, bool is_per_vcpu, void *cb_data)
+{
+ struct ffa_drv_info *info = cb_data;
+
+ if (!is_per_vcpu)
+ notif_pcpu_irq_work_fn(&info->notif_pcpu_work);
+ else
+ queue_work_on(vcpu, info->notif_pcpu_wq,
+ &info->notif_pcpu_work);
+}
+
static const struct ffa_info_ops ffa_drv_info_ops = {
.api_version_get = ffa_api_version_get,
.partition_info_get = ffa_partition_info_get,
@@ -1160,6 +1213,13 @@ static void ffa_setup_partitions(void)
drv_info->partition_count = count;

kfree(pbuf);
+
+ /* Allocate for the host */
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return;
+ xa_store(&drv_info->partition_info, drv_info->vm_id, info, GFP_KERNEL);
+ drv_info->partition_count++;
}

static void ffa_partitions_cleanup(void)
@@ -1303,6 +1363,7 @@ static int ffa_init_pcpu_irq(unsigned int irq)
}

INIT_WORK(&drv_info->irq_work, ffa_sched_recv_irq_work_fn);
+ INIT_WORK(&drv_info->notif_pcpu_work, notif_pcpu_irq_work_fn);
drv_info->notif_pcpu_wq = create_workqueue("ffa_pcpu_irq_notification");
if (!drv_info->notif_pcpu_wq)
return -EINVAL;
@@ -1360,7 +1421,9 @@ static int ffa_notifications_setup(void)
hash_init(drv_info->notifier_hash);
mutex_init(&drv_info->notify_lock);

- return 0;
+ /* Register internal scheduling callback */
+ return ffa_sched_recv_cb_update(drv_info->vm_id,
+ ffa_self_notif_handle, drv_info, true);
cleanup:
ffa_notifications_cleanup();
return ret;

--
2.42.0

2023-09-29 15:52:03

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 05/17] firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interface

The framework provides an interface to the sender to specify the
notification to signal to the receiver. A sender signals a notification
by requesting its partition manager to set the corresponding bit in the
notifications bitmap of the receiver invoking FFA_NOTIFICATION_SET.

Implement the FFA_NOTIFICATION_SET to enable the caller(sender) to send
the notifications for any other partitions in the system.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b265063e76ea..b0d1ddfe0230 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -616,6 +616,26 @@ static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
return 0;
}

+static
+int ffa_notification_set(u16 src_id, u16 dst_id, u32 flags, u64 bitmap)
+{
+ ffa_value_t ret;
+ u32 src_dst_ids = PACK_TARGET_INFO(dst_id, src_id);
+
+ invoke_ffa_fn((ffa_value_t) {
+ .a0 = FFA_NOTIFICATION_SET, .a1 = src_dst_ids, .a2 = flags,
+ .a3 = NOTIFICATION_BITMAP_LOW(bitmap),
+ .a4 = NOTIFICATION_BITMAP_HIGH(bitmap),
+ }, &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+ else if (ret.a0 != FFA_SUCCESS)
+ return -EINVAL;
+
+ return 0;
+}
+
static int ffa_run(struct ffa_device *dev, u16 vcpu)
{
ffa_value_t ret;

--
2.42.0

2023-09-29 15:52:04

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 01/17] firmware: arm_ffa: Update the FF-A command list with v1.1 additions

Arm Firmware Framework for A-profile(FFA) v1.1 introduces notifications
and indirect messaging based upon notifications support and extends some
of the memory interfaces.

Let us add all the newly supported FF-A function IDs in the spec.
Also update to the error values and associated handling.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 3 ++-
include/linux/arm_ffa.h | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 121f4fc903cd..2b24cda2a185 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -64,6 +64,7 @@ static const int ffa_linux_errmap[] = {
-EACCES, /* FFA_RET_DENIED */
-EAGAIN, /* FFA_RET_RETRY */
-ECANCELED, /* FFA_RET_ABORTED */
+ -ENODATA, /* FFA_RET_NO_DATA */
};

static inline int ffa_to_linux_errno(int errno)
@@ -336,7 +337,7 @@ static int ffa_mem_first_frag(u32 func_id, phys_addr_t buf, u32 buf_sz,
if (ret.a0 == FFA_ERROR)
return ffa_to_linux_errno((int)ret.a2);

- if (ret.a0 == FFA_SUCCESS) {
+ if (ret.a0 == FFA_SUCCESS || ret.a0 == FFA_FN64_SUCCESS) {
if (handle)
*handle = PACK_HANDLE(ret.a2, ret.a3);
} else if (ret.a0 == FFA_MEM_FRAG_RX) {
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index cc060da51bec..2ea1717a0825 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -20,6 +20,7 @@

#define FFA_ERROR FFA_SMC_32(0x60)
#define FFA_SUCCESS FFA_SMC_32(0x61)
+#define FFA_FN64_SUCCESS FFA_SMC_64(0x61)
#define FFA_INTERRUPT FFA_SMC_32(0x62)
#define FFA_VERSION FFA_SMC_32(0x63)
#define FFA_FEATURES FFA_SMC_32(0x64)
@@ -54,6 +55,23 @@
#define FFA_MEM_FRAG_RX FFA_SMC_32(0x7A)
#define FFA_MEM_FRAG_TX FFA_SMC_32(0x7B)
#define FFA_NORMAL_WORLD_RESUME FFA_SMC_32(0x7C)
+#define FFA_NOTIFICATION_BITMAP_CREATE FFA_SMC_32(0x7D)
+#define FFA_NOTIFICATION_BITMAP_DESTROY FFA_SMC_32(0x7E)
+#define FFA_NOTIFICATION_BIND FFA_SMC_32(0x7F)
+#define FFA_NOTIFICATION_UNBIND FFA_SMC_32(0x80)
+#define FFA_NOTIFICATION_SET FFA_SMC_32(0x81)
+#define FFA_NOTIFICATION_GET FFA_SMC_32(0x82)
+#define FFA_NOTIFICATION_INFO_GET FFA_SMC_32(0x83)
+#define FFA_FN64_NOTIFICATION_INFO_GET FFA_SMC_64(0x83)
+#define FFA_RX_ACQUIRE FFA_SMC_32(0x84)
+#define FFA_SPM_ID_GET FFA_SMC_32(0x85)
+#define FFA_MSG_SEND2 FFA_SMC_32(0x86)
+#define FFA_SECONDARY_EP_REGISTER FFA_SMC_32(0x87)
+#define FFA_FN64_SECONDARY_EP_REGISTER FFA_SMC_64(0x87)
+#define FFA_MEM_PERM_GET FFA_SMC_32(0x88)
+#define FFA_FN64_MEM_PERM_GET FFA_SMC_64(0x88)
+#define FFA_MEM_PERM_SET FFA_SMC_32(0x89)
+#define FFA_FN64_MEM_PERM_SET FFA_SMC_64(0x89)

/*
* For some calls it is necessary to use SMC64 to pass or return 64-bit values.
@@ -76,6 +94,7 @@
#define FFA_RET_DENIED (-6)
#define FFA_RET_RETRY (-7)
#define FFA_RET_ABORTED (-8)
+#define FFA_RET_NO_DATA (-9)

/* FFA version encoding */
#define FFA_MAJOR_VERSION_MASK GENMASK(30, 16)
@@ -86,6 +105,7 @@
(FIELD_PREP(FFA_MAJOR_VERSION_MASK, (major)) | \
FIELD_PREP(FFA_MINOR_VERSION_MASK, (minor)))
#define FFA_VERSION_1_0 FFA_PACK_VERSION_INFO(1, 0)
+#define FFA_VERSION_1_1 FFA_PACK_VERSION_INFO(1, 1)

/**
* FF-A specification mentions explicitly about '4K pages'. This should

--
2.42.0

2023-09-29 15:52:05

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 11/17] firmware: arm_ffa: Add interface to send a notification to a given partition

The framework provides an interface to the sender endpoint to specify
the notification to signal to the receiver endpoint. A sender signals
a notification by requesting its partition manager to set the
corresponding bit in the notifications bitmap of the receiver.

Expose the ability to send a notification to another partition.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 13 +++++++++++++
include/linux/arm_ffa.h | 2 ++
2 files changed, 15 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 55707a5d333d..94e39ee83278 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1044,6 +1044,18 @@ static int ffa_notify_request(struct ffa_device *dev, bool is_per_vcpu,
return rc;
}

+static int ffa_notify_send(struct ffa_device *dev, int notify_id,
+ bool is_per_vcpu, u16 vcpu)
+{
+ u32 flags = 0;
+
+ if (is_per_vcpu)
+ flags |= (PER_VCPU_NOTIFICATION_FLAG | vcpu << 16);
+
+ return ffa_notification_set(dev->vm_id, drv_info->vm_id, flags,
+ BIT(notify_id));
+}
+
static const struct ffa_info_ops ffa_drv_info_ops = {
.api_version_get = ffa_api_version_get,
.partition_info_get = ffa_partition_info_get,
@@ -1069,6 +1081,7 @@ static const struct ffa_notifier_ops ffa_drv_notifier_ops = {
.sched_recv_cb_unregister = ffa_sched_recv_cb_unregister,
.notify_request = ffa_notify_request,
.notify_relinquish = ffa_notify_relinquish,
+ .notify_send = ffa_notify_send,
};

static const struct ffa_ops ffa_drv_ops = {
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index fb6f388a3737..f6df81f14b6d 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -401,6 +401,8 @@ struct ffa_notifier_ops {
int (*notify_request)(struct ffa_device *dev, bool per_vcpu,
ffa_notifier_cb cb, void *cb_data, int notify_id);
int (*notify_relinquish)(struct ffa_device *dev, int notify_id);
+ int (*notify_send)(struct ffa_device *dev, int notify_id, bool per_vcpu,
+ u16 vcpu);
};

struct ffa_ops {

--
2.42.0

2023-09-29 15:52:11

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 06/17] firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interface

The framework provides an interface to the receiver to determine the
identity of the notification. A receiver endpoint must use the
FFA_NOTIFICATION_GET interface to retrieve its pending notifications
and handle them.

Add the support for FFA_NOTIFICATION_GET to allow the caller(receiver)
to fetch its pending notifications from other partitions in the system.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b0d1ddfe0230..02eedb7bc171 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -593,6 +593,14 @@ static int ffa_notification_bitmap_destroy(void)
((u32)(FIELD_GET(NOTIFICATION_HIGH_MASK, (x))))
#define NOTIFICATION_BITMAP_LOW(x) \
((u32)(FIELD_GET(NOTIFICATION_LOW_MASK, (x))))
+#define PACK_NOTIFICATION_BITMAP(low, high) \
+ (FIELD_PREP(NOTIFICATION_LOW_MASK, (low)) | \
+ FIELD_PREP(NOTIFICATION_HIGH_MASK, (high)))
+
+#define RECEIVER_VCPU_MASK GENMASK(31, 16)
+#define PACK_NOTIFICATION_GET_RECEIVER_INFO(vcpu_r, r) \
+ (FIELD_PREP(RECEIVER_VCPU_MASK, (vcpu_r)) | \
+ FIELD_PREP(RECEIVER_ID_MASK, (r)))

static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
u32 flags, bool is_bind)
@@ -636,6 +644,35 @@ int ffa_notification_set(u16 src_id, u16 dst_id, u32 flags, u64 bitmap)
return 0;
}

+struct ffa_notify_bitmaps {
+ u64 sp_map;
+ u64 vm_map;
+ u64 arch_map;
+};
+
+static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
+{
+ ffa_value_t ret;
+ u16 src_id = drv_info->vm_id;
+ u16 cpu_id = smp_processor_id();
+ u32 rec_vcpu_ids = PACK_NOTIFICATION_GET_RECEIVER_INFO(cpu_id, src_id);
+
+ invoke_ffa_fn((ffa_value_t){
+ .a0 = FFA_NOTIFICATION_GET, .a1 = rec_vcpu_ids, .a2 = flags,
+ }, &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+ else if (ret.a0 != FFA_SUCCESS)
+ return -EINVAL; /* Something else went wrong. */
+
+ notify->sp_map = PACK_NOTIFICATION_BITMAP(ret.a2, ret.a3);
+ notify->vm_map = PACK_NOTIFICATION_BITMAP(ret.a4, ret.a5);
+ notify->arch_map = PACK_NOTIFICATION_BITMAP(ret.a6, ret.a7);
+
+ return 0;
+}
+
static int ffa_run(struct ffa_device *dev, u16 vcpu)
{
ffa_value_t ret;

--
2.42.0

2023-09-29 15:52:12

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH v3 02/17] firmware: arm_ffa: Implement notification bitmap create and destroy interfaces

On systems without a hypervisor the responsibility of requesting the
creation of the notification bitmaps in the SPM falls to the FF-A driver.

We use FFA features to determine if the ABI is supported, if it is not
we can assume there is a hypervisor present and will take care of ensure
the relevant notifications bitmaps are created on this partitions behalf.

An endpoint’s notification bitmaps needs to be setup before it configures
its notifications and before other endpoints and partition managers can
start signaling these notifications.

Add interface to create and destroy the notification bitmaps and use the
same to do the necessary setup during the initialisation and cleanup
during the module exit.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_ffa/driver.c | 60 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 2b24cda2a185..efa4e7fb15e3 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -84,6 +84,7 @@ struct ffa_drv_info {
void *rx_buffer;
void *tx_buffer;
bool mem_ops_native;
+ bool bitmap_created;
};

static struct ffa_drv_info *drv_info;
@@ -555,6 +556,37 @@ static int ffa_features(u32 func_feat_id, u32 input_props,
return 0;
}

+static int ffa_notification_bitmap_create(void)
+{
+ ffa_value_t ret;
+ u16 vcpu_count = nr_cpu_ids;
+
+ invoke_ffa_fn((ffa_value_t){
+ .a0 = FFA_NOTIFICATION_BITMAP_CREATE,
+ .a1 = drv_info->vm_id, .a2 = vcpu_count,
+ }, &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+
+ return 0;
+}
+
+static int ffa_notification_bitmap_destroy(void)
+{
+ ffa_value_t ret;
+
+ invoke_ffa_fn((ffa_value_t){
+ .a0 = FFA_NOTIFICATION_BITMAP_DESTROY,
+ .a1 = drv_info->vm_id,
+ }, &ret);
+
+ if (ret.a0 == FFA_ERROR)
+ return ffa_to_linux_errno((int)ret.a2);
+
+ return 0;
+}
+
static void ffa_set_up_mem_ops_native_flag(void)
{
if (!ffa_features(FFA_FN_NATIVE(MEM_LEND), 0, NULL, NULL) ||
@@ -712,6 +744,31 @@ static void ffa_setup_partitions(void)
kfree(pbuf);
}

+static int ffa_notifications_setup(void)
+{
+ int ret;
+
+ ret = ffa_features(FFA_NOTIFICATION_BITMAP_CREATE, 0, NULL, NULL);
+ if (!ret) {
+ ret = ffa_notification_bitmap_create();
+ if (ret) {
+ pr_err("notification_bitmap_create error %d\n", ret);
+ return ret;
+ }
+ }
+ drv_info->bitmap_created = true;
+
+ return 0;
+}
+
+static void ffa_notifications_cleanup(void)
+{
+ if (drv_info->bitmap_created) {
+ ffa_notification_bitmap_destroy();
+ drv_info->bitmap_created = false;
+ }
+}
+
static int __init ffa_init(void)
{
int ret;
@@ -767,7 +824,7 @@ static int __init ffa_init(void)

ffa_set_up_mem_ops_native_flag();

- return 0;
+ return ffa_notifications_setup();
free_pages:
if (drv_info->tx_buffer)
free_pages_exact(drv_info->tx_buffer, RXTX_BUFFER_SIZE);
@@ -782,6 +839,7 @@ subsys_initcall(ffa_init);

static void __exit ffa_exit(void)
{
+ ffa_notifications_cleanup();
ffa_rxtx_unmap(drv_info->vm_id);
free_pages_exact(drv_info->tx_buffer, RXTX_BUFFER_SIZE);
free_pages_exact(drv_info->rx_buffer, RXTX_BUFFER_SIZE);

--
2.42.0

2023-10-02 19:57:14

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 14/17] KVM: arm64: FFA: Remove access of endpoint memory access descriptor array

On Fri, Sep 29, 2023 at 04:03:03PM +0100, Sudeep Holla wrote:
> FF-A v1.1 removes the fixed location of endpoint memory access descriptor
> array within the memory transaction descriptor structure. In preparation
> to remove the ep_mem_access member from the ffa_mem_region structure,
> provide the accessor to fetch the offset and use the same in FF-A proxy
> implementation.
>
> The accessor take the boolean argument that indicates if the memory access
> descriptor versions is v1(old format) or not. Currently it is set true as
> FF-A proxy supports only v1.0
>

Will, Marc,

Can you please provide your Ack if you are OK with this change so that I can
take the series via Arm SoC ? I kept the KVM change independent and the patch
removing the structure member is 16/17[1]

--
Regards,
Sudeep

[1] https://lore.kernel.org/all/[email protected]

2023-10-04 09:11:37

by Jens Wiklander

[permalink] [raw]
Subject: Re: [PATCH v3 07/17] firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface

On Fri, Sep 29, 2023 at 04:02:56PM +0100, Sudeep Holla wrote:
> The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface
> to retrieve the list of endpoints that have pending notifications and
> must be run. A notification could be signaled by a sender in the secure
> world to a VM. The Hypervisor needs to determine which VM and vCPU
> (in case a per-vCPU notification is signaled) has a pending notification
> in this scenario. It must obtain this information through an invocation
> of the FFA_NOTIFICATION_INFO_GET.
>
> Add the implementation of the NOTIFICATION_INFO_GET interface
> and prepare to use this to handle the schedule receiver interrupt.
> Implementation of handling notifications will be added later.
>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> drivers/firmware/arm_ffa/driver.c | 70 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index 02eedb7bc171..dfeeb751bebe 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -602,6 +602,13 @@ static int ffa_notification_bitmap_destroy(void)
> (FIELD_PREP(RECEIVER_VCPU_MASK, (vcpu_r)) | \
> FIELD_PREP(RECEIVER_ID_MASK, (r)))
>
> +#define NOTIFICATION_INFO_GET_MORE_PEND_MASK BIT(0)
> +#define NOTIFICATION_INFO_GET_ID_COUNT GENMASK(11, 7)
> +#define ID_LIST_MASK_64 GENMASK(51, 12)
> +#define ID_LIST_MASK_32 GENMASK(31, 12)
> +#define MAX_IDS_64 20
> +#define MAX_IDS_32 10
> +
> static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
> u32 flags, bool is_bind)
> {
> @@ -673,6 +680,69 @@ static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
> return 0;
> }
>
> +static void __do_sched_recv_cb(u16 partition_id, u16 vcpu, bool is_per_vcpu)
> +{
> + pr_err("Callback for partition 0x%x failed.\n", partition_id);
> +}
> +
> +static void ffa_notification_info_get(bool is_64b)
> +{
> + int idx, list, max_ids, lists_cnt, ids_processed, ids_count[MAX_IDS_64];
> + ffa_value_t ret;
> + u64 id_list;
> +
> + do {
> + invoke_ffa_fn((ffa_value_t){
> + .a0 = FFA_FN_NATIVE(NOTIFICATION_INFO_GET),
> + }, &ret);
> +
> + if (ret.a0 != FFA_FN_NATIVE(SUCCESS)) {

The specification doesn't require a response using 64-bit SMCCC, it is
valid to respond using 32-bit SMCCC too.

Thanks,
Jens

> + if (ret.a2 != FFA_RET_NO_DATA)
> + pr_err("Notification Info fetch failed: 0x%lx (0x%lx)",
> + ret.a0, ret.a2);
> + return;
> + }
> +
> + ids_processed = 0;
> + lists_cnt = FIELD_GET(NOTIFICATION_INFO_GET_ID_COUNT, ret.a2);
> + if (is_64b) {
> + max_ids = MAX_IDS_64;
> + id_list = FIELD_GET(ID_LIST_MASK_64, ret.a2);
> + } else {
> + max_ids = MAX_IDS_32;
> + id_list = FIELD_GET(ID_LIST_MASK_32, ret.a2);
> + }
> +
> + for (idx = 0; idx < lists_cnt; idx++, id_list >>= 2)
> + ids_count[idx] = (id_list & 0x3) + 1;
> +
> + /* Process IDs */
> + for (list = 0; list < lists_cnt; list++) {
> + u16 vcpu_id, part_id, *packed_id_list = (u16 *)&ret.a3;
> +
> + if (ids_processed >= max_ids - 1)
> + break;
> +
> + part_id = packed_id_list[++ids_processed];
> +
> + if (!ids_count[list]) { /* Global Notification */
> + __do_sched_recv_cb(part_id, 0, false);
> + continue;
> + }
> +
> + /* Per vCPU Notification */
> + for (idx = 0; idx < ids_count[list]; idx++) {
> + if (ids_processed >= max_ids - 1)
> + break;
> +
> + vcpu_id = packed_id_list[++ids_processed];
> +
> + __do_sched_recv_cb(part_id, vcpu_id, true);
> + }
> + }
> + } while (ret.a2 & NOTIFICATION_INFO_GET_MORE_PEND_MASK);
> +}
> +
> static int ffa_run(struct ffa_device *dev, u16 vcpu)
> {
> ffa_value_t ret;
>
> --
> 2.42.0
>

2023-10-04 09:12:13

by Jens Wiklander

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Fri, Sep 29, 2023 at 04:02:52PM +0100, Sudeep Holla wrote:
> A receiver endpoint must bind a notification to any sender endpoint
> before the latter can signal the notification to the former. The receiver
> assigns one or more doorbells to a specific sender. Only the sender can
> ring these doorbells.
>
> A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
> notifications to the sender. A receiver un-binds a notification from a
> sender endpoint to stop the notification from being signaled. It uses
> the FFA_NOTIFICATION_UNBIND interface to do this.
>
> Allow the FF-A driver to be able to bind and unbind a given notification
> ID to a specific partition ID. This will be used to register and
> unregister notification callbacks from the FF-A client drivers.
>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> drivers/firmware/arm_ffa/driver.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index efa4e7fb15e3..26bf9c4e3b5f 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -587,6 +587,35 @@ static int ffa_notification_bitmap_destroy(void)
> return 0;
> }
>
> +#define NOTIFICATION_LOW_MASK GENMASK(31, 0)
> +#define NOTIFICATION_HIGH_MASK GENMASK(63, 32)
> +#define NOTIFICATION_BITMAP_HIGH(x) \
> + ((u32)(FIELD_GET(NOTIFICATION_HIGH_MASK, (x))))
> +#define NOTIFICATION_BITMAP_LOW(x) \
> + ((u32)(FIELD_GET(NOTIFICATION_LOW_MASK, (x))))
> +
> +static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
> + u32 flags, bool is_bind)
> +{
> + ffa_value_t ret;
> + u32 func, src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);

dst_id and drv_info->vm_id should be swapped.

Thanks,
Jens

> +
> + func = is_bind ? FFA_NOTIFICATION_BIND : FFA_NOTIFICATION_UNBIND;
> +
> + invoke_ffa_fn((ffa_value_t){
> + .a0 = func, .a1 = src_dst_ids, .a2 = flags,
> + .a3 = NOTIFICATION_BITMAP_LOW(bitmap),
> + .a4 = NOTIFICATION_BITMAP_HIGH(bitmap),
> + }, &ret);
> +
> + if (ret.a0 == FFA_ERROR)
> + return ffa_to_linux_errno((int)ret.a2);
> + else if (ret.a0 != FFA_SUCCESS)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static void ffa_set_up_mem_ops_native_flag(void)
> {
> if (!ffa_features(FFA_FN_NATIVE(MEM_LEND), 0, NULL, NULL) ||
>
> --
> 2.42.0
>

2023-10-04 09:51:37

by Olivier Deprez

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

Hi Jens,

> dst_id and drv_info->vm_id should be swapped.

I'm curious about this because swapping like this actually makes hafnium fail. Need to check from the spec.

Regards,
Olivier.



________________________________________
From: Jens Wiklander <[email protected]>
Sent: 04 October 2023 11:11
To: Sudeep Holla
Cc: [email protected]; [email protected]; Marc Bonnici; Coboy Chen; Lorenzo Pieralisi; Olivier Deprez
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Fri, Sep 29, 2023 at 04:02:52PM +0100, Sudeep Holla wrote:
> A receiver endpoint must bind a notification to any sender endpoint
> before the latter can signal the notification to the former. The receiver
> assigns one or more doorbells to a specific sender. Only the sender can
> ring these doorbells.
>
> A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
> notifications to the sender. A receiver un-binds a notification from a
> sender endpoint to stop the notification from being signaled. It uses
> the FFA_NOTIFICATION_UNBIND interface to do this.
>
> Allow the FF-A driver to be able to bind and unbind a given notification
> ID to a specific partition ID. This will be used to register and
> unregister notification callbacks from the FF-A client drivers.
>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> drivers/firmware/arm_ffa/driver.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index efa4e7fb15e3..26bf9c4e3b5f 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -587,6 +587,35 @@ static int ffa_notification_bitmap_destroy(void)
> return 0;
> }
>
> +#define NOTIFICATION_LOW_MASK GENMASK(31, 0)
> +#define NOTIFICATION_HIGH_MASK GENMASK(63, 32)
> +#define NOTIFICATION_BITMAP_HIGH(x) \
> + ((u32)(FIELD_GET(NOTIFICATION_HIGH_MASK, (x))))
> +#define NOTIFICATION_BITMAP_LOW(x) \
> + ((u32)(FIELD_GET(NOTIFICATION_LOW_MASK, (x))))
> +
> +static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
> + u32 flags, bool is_bind)
> +{
> + ffa_value_t ret;
> + u32 func, src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);

dst_id and drv_info->vm_id should be swapped.

Thanks,
Jens

> +
> + func = is_bind ? FFA_NOTIFICATION_BIND : FFA_NOTIFICATION_UNBIND;
> +
> + invoke_ffa_fn((ffa_value_t){
> + .a0 = func, .a1 = src_dst_ids, .a2 = flags,
> + .a3 = NOTIFICATION_BITMAP_LOW(bitmap),
> + .a4 = NOTIFICATION_BITMAP_HIGH(bitmap),
> + }, &ret);
> +
> + if (ret.a0 == FFA_ERROR)
> + return ffa_to_linux_errno((int)ret.a2);
> + else if (ret.a0 != FFA_SUCCESS)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static void ffa_set_up_mem_ops_native_flag(void)
> {
> if (!ffa_features(FFA_FN_NATIVE(MEM_LEND), 0, NULL, NULL) ||
>
> --
> 2.42.0
>

2023-10-04 10:08:40

by Marc Zyngier

[permalink] [raw]
Subject: Re: [PATCH v3 14/17] KVM: arm64: FFA: Remove access of endpoint memory access descriptor array

On Fri, 29 Sep 2023 16:03:03 +0100,
Sudeep Holla <[email protected]> wrote:
>
> FF-A v1.1 removes the fixed location of endpoint memory access descriptor
> array within the memory transaction descriptor structure. In preparation
> to remove the ep_mem_access member from the ffa_mem_region structure,
> provide the accessor to fetch the offset and use the same in FF-A proxy
> implementation.
>
> The accessor take the boolean argument that indicates if the memory access
> descriptor versions is v1(old format) or not. Currently it is set true as
> FF-A proxy supports only v1.0
>
> Cc: Marc Zyngier <[email protected]>
> Cc: Oliver Upton <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Quentin Perret <[email protected]>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 8 ++++++--
> include/linux/arm_ffa.h | 6 ++++++
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 6e4dba9eadef..5f956f53e6bf 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -423,6 +423,7 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
> DECLARE_REG(u32, fraglen, ctxt, 2);
> DECLARE_REG(u64, addr_mbz, ctxt, 3);
> DECLARE_REG(u32, npages_mbz, ctxt, 4);
> + struct ffa_mem_region_attributes *ep_mem_access;
> struct ffa_composite_mem_region *reg;
> struct ffa_mem_region *buf;
> u32 offset, nr_ranges;
> @@ -452,7 +453,8 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
> buf = hyp_buffers.tx;
> memcpy(buf, host_buffers.tx, fraglen);
>
> - offset = buf->ep_mem_access[0].composite_off;
> + ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
> + offset = ep_mem_access->composite_off;
> if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
> ret = FFA_RET_INVALID_PARAMETERS;
> goto out_unlock;
> @@ -504,6 +506,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
> DECLARE_REG(u32, handle_lo, ctxt, 1);
> DECLARE_REG(u32, handle_hi, ctxt, 2);
> DECLARE_REG(u32, flags, ctxt, 3);
> + struct ffa_mem_region_attributes *ep_mem_access;
> struct ffa_composite_mem_region *reg;
> u32 offset, len, fraglen, fragoff;
> struct ffa_mem_region *buf;
> @@ -528,7 +531,8 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
> len = res->a1;
> fraglen = res->a2;
>
> - offset = buf->ep_mem_access[0].composite_off;
> + ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
> + offset = ep_mem_access->composite_off;
> /*
> * We can trust the SPMD to get this right, but let's at least
> * check that we end up with something that doesn't look _completely_
> diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
> index 748d0a83a4bc..7be240e37f36 100644
> --- a/include/linux/arm_ffa.h
> +++ b/include/linux/arm_ffa.h
> @@ -357,6 +357,12 @@ struct ffa_mem_region {
> #define CONSTITUENTS_OFFSET(x) \
> (offsetof(struct ffa_composite_mem_region, constituents[x]))
>
> +static inline u32
> +ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, bool mem_desc_v1)
> +{
> + return COMPOSITE_OFFSET(0);
> +}

If the goal of this patch is to introduce some versioning, why not
define this last parameter as an actual version number, PSCI style
(with a minor and major, each on a 16bit field)?

Even the name is pretty misleading, as both FFA versions are v1 (v1.0
vs v1.1...).

Thanks,

M.

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

2023-10-04 13:23:12

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 14/17] KVM: arm64: FFA: Remove access of endpoint memory access descriptor array

On Wed, Oct 04, 2023 at 11:08:23AM +0100, Marc Zyngier wrote:
> On Fri, 29 Sep 2023 16:03:03 +0100,
> Sudeep Holla <[email protected]> wrote:
> >
> > FF-A v1.1 removes the fixed location of endpoint memory access descriptor
> > array within the memory transaction descriptor structure. In preparation
> > to remove the ep_mem_access member from the ffa_mem_region structure,
> > provide the accessor to fetch the offset and use the same in FF-A proxy
> > implementation.
> >
> > The accessor take the boolean argument that indicates if the memory access
> > descriptor versions is v1(old format) or not. Currently it is set true as
> > FF-A proxy supports only v1.0
> >
> > Cc: Marc Zyngier <[email protected]>
> > Cc: Oliver Upton <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Cc: Quentin Perret <[email protected]>
> > Signed-off-by: Sudeep Holla <[email protected]>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 8 ++++++--
> > include/linux/arm_ffa.h | 6 ++++++
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 6e4dba9eadef..5f956f53e6bf 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -423,6 +423,7 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
> > DECLARE_REG(u32, fraglen, ctxt, 2);
> > DECLARE_REG(u64, addr_mbz, ctxt, 3);
> > DECLARE_REG(u32, npages_mbz, ctxt, 4);
> > + struct ffa_mem_region_attributes *ep_mem_access;
> > struct ffa_composite_mem_region *reg;
> > struct ffa_mem_region *buf;
> > u32 offset, nr_ranges;
> > @@ -452,7 +453,8 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
> > buf = hyp_buffers.tx;
> > memcpy(buf, host_buffers.tx, fraglen);
> >
> > - offset = buf->ep_mem_access[0].composite_off;
> > + ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
> > + offset = ep_mem_access->composite_off;
> > if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
> > ret = FFA_RET_INVALID_PARAMETERS;
> > goto out_unlock;
> > @@ -504,6 +506,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
> > DECLARE_REG(u32, handle_lo, ctxt, 1);
> > DECLARE_REG(u32, handle_hi, ctxt, 2);
> > DECLARE_REG(u32, flags, ctxt, 3);
> > + struct ffa_mem_region_attributes *ep_mem_access;
> > struct ffa_composite_mem_region *reg;
> > u32 offset, len, fraglen, fragoff;
> > struct ffa_mem_region *buf;
> > @@ -528,7 +531,8 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
> > len = res->a1;
> > fraglen = res->a2;
> >
> > - offset = buf->ep_mem_access[0].composite_off;
> > + ep_mem_access = (void *)buf + ffa_mem_desc_offset(buf, 0, true);
> > + offset = ep_mem_access->composite_off;
> > /*
> > * We can trust the SPMD to get this right, but let's at least
> > * check that we end up with something that doesn't look _completely_
> > diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
> > index 748d0a83a4bc..7be240e37f36 100644
> > --- a/include/linux/arm_ffa.h
> > +++ b/include/linux/arm_ffa.h
> > @@ -357,6 +357,12 @@ struct ffa_mem_region {
> > #define CONSTITUENTS_OFFSET(x) \
> > (offsetof(struct ffa_composite_mem_region, constituents[x]))
> >
> > +static inline u32
> > +ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, bool mem_desc_v1)
> > +{
> > + return COMPOSITE_OFFSET(0);
> > +}
>
> If the goal of this patch is to introduce some versioning, why not
> define this last parameter as an actual version number, PSCI style
> (with a minor and major, each on a 16bit field)?
>

Fair enough. I am being optimistic that the memory descriptor format doesn't
change with each FF-A version. And the v2 of the memory descriptor format is
quite flexible to provide backward compatibility for some time(I agree that
is controversial :))

> Even the name is pretty misleading, as both FFA versions are v1 (v1.0
> vs v1.1...).
>

I was referring to the memory descriptor format version. The intention was
to keep it separate from the FF-A version. But if using FF-A version makes
things simpler I can go for that.

--
Regards,
Sudeep

2023-10-04 15:11:33

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 07/17] firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface

On Wed, Oct 04, 2023 at 11:10:21AM +0200, Jens Wiklander wrote:
> On Fri, Sep 29, 2023 at 04:02:56PM +0100, Sudeep Holla wrote:
> > The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface
> > to retrieve the list of endpoints that have pending notifications and
> > must be run. A notification could be signaled by a sender in the secure
> > world to a VM. The Hypervisor needs to determine which VM and vCPU
> > (in case a per-vCPU notification is signaled) has a pending notification
> > in this scenario. It must obtain this information through an invocation
> > of the FFA_NOTIFICATION_INFO_GET.
> >
> > Add the implementation of the NOTIFICATION_INFO_GET interface
> > and prepare to use this to handle the schedule receiver interrupt.
> > Implementation of handling notifications will be added later.
> >
> > Signed-off-by: Sudeep Holla <[email protected]>
> > ---
> > drivers/firmware/arm_ffa/driver.c | 70 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index 02eedb7bc171..dfeeb751bebe 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -602,6 +602,13 @@ static int ffa_notification_bitmap_destroy(void)
> > (FIELD_PREP(RECEIVER_VCPU_MASK, (vcpu_r)) | \
> > FIELD_PREP(RECEIVER_ID_MASK, (r)))
> >
> > +#define NOTIFICATION_INFO_GET_MORE_PEND_MASK BIT(0)
> > +#define NOTIFICATION_INFO_GET_ID_COUNT GENMASK(11, 7)
> > +#define ID_LIST_MASK_64 GENMASK(51, 12)
> > +#define ID_LIST_MASK_32 GENMASK(31, 12)
> > +#define MAX_IDS_64 20
> > +#define MAX_IDS_32 10
> > +
> > static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
> > u32 flags, bool is_bind)
> > {
> > @@ -673,6 +680,69 @@ static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
> > return 0;
> > }
> >
> > +static void __do_sched_recv_cb(u16 partition_id, u16 vcpu, bool is_per_vcpu)
> > +{
> > + pr_err("Callback for partition 0x%x failed.\n", partition_id);
> > +}
> > +
> > +static void ffa_notification_info_get(bool is_64b)
> > +{
> > + int idx, list, max_ids, lists_cnt, ids_processed, ids_count[MAX_IDS_64];
> > + ffa_value_t ret;
> > + u64 id_list;
> > +
> > + do {
> > + invoke_ffa_fn((ffa_value_t){
> > + .a0 = FFA_FN_NATIVE(NOTIFICATION_INFO_GET),
> > + }, &ret);
> > +
> > + if (ret.a0 != FFA_FN_NATIVE(SUCCESS)) {
>
> The specification doesn't require a response using 64-bit SMCCC, it is
> valid to respond using 32-bit SMCCC too.
>

Do you mean to say the we need to support 64b NOTIFICATION_INFO_GET
returning 32b FFA_SUCCESS ? If so do we need to assume only 32bits are
used in the result. As per the specification,

"0xC4000061(FFA_FN64_SUCCESS): This function ID is used only if any result
register encodes a 64-bit parameter."

My question is what that means allowing 32bit FFA_SUCCESS here?

--
Regards,
Sudeep

2023-10-04 15:32:52

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Wed, Oct 04, 2023 at 10:50:26AM +0100, Olivier Deprez wrote:
> Hi Jens,
>
> > dst_id and drv_info->vm_id should be swapped.
>
> I'm curious about this because swapping like this actually makes hafnium
> fail. Need to check from the spec.

I did check after I had swapped this in v2(because I was convinced Jens) was
correct and you reported the failure. Reading the spec again the other day,
I got corrected myself and agreed with Olivier and my original
implementation(v1) which matches this patch(v3).

--
Regards,
Sudeep

2023-10-05 13:57:50

by Jens Wiklander

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Thu, Oct 5, 2023 at 10:51 AM Sudeep Holla <[email protected]> wrote:
>
> On Thu, Oct 05, 2023 at 08:57:26AM +0200, Jens Wiklander wrote:
> > Hi Sudeep,
> >
> > On Wed, Oct 4, 2023 at 5:32 PM Sudeep Holla <[email protected]> wrote:
> > >
> > > On Wed, Oct 04, 2023 at 10:50:26AM +0100, Olivier Deprez wrote:
> > > > Hi Jens,
> > > >
> > > > > dst_id and drv_info->vm_id should be swapped.
> > > >
> > > > I'm curious about this because swapping like this actually makes hafnium
> > > > fail. Need to check from the spec.
> > >
> > > I did check after I had swapped this in v2(because I was convinced Jens) was
> > > correct and you reported the failure. Reading the spec again the other day,
> > > I got corrected myself and agreed with Olivier and my original
> > > implementation(v1) which matches this patch(v3).
>
> Well, I am not exactly sure what is the root cause for the confusion here:
> My poor choice of variable names and their usage with this macro, or the
> macro definition itself(I am not sure)
>
> OR
>
> The wordings in the specification
>
> >
> > I don't get it. The spec says for FFA_NOTIFICATION_BIND:
> > Sender and Receiver endpoint IDs.
> > – Bit[31:16]: Sender endpoint ID.
> > – Bit[15:0]: Receiver endpoint ID.
> > This is exactly the same as for instance FFA_MSG_SEND_DIRECT_REQ.
> >
>
> Not really as per my understanding of the specification.
>
> > In ffa_msg_send_direct_req() you assign
> > src_dst_ids = PACK_TARGET_INFO(src_id, dst_id);
> >
>
> Correct and if you look at the callsite, it is
> ffa_msg_send_direct_req(drv_info->vm_id, dev->vm_id,...)
>
> So the driver is the sender and the partition is the receiver. Probably
> this is simpler.
>
> > but here in ffa_notification_bind_common() you assign
> > src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);
> >
>
> A receiver(FF-A driver) must bind a non-framework notification to a
> sender(SP) before the latter can signal the notification to the former.
> Only the sender can ring these doorbells. A receiver uses the
> FFA_NOTIFICATION_BIND interface to bind one or more notifications to the
> sender.
>
> So, based on this text(modified to refer sender and receiver in the driver
> context) from the spec, my understanding is the driver is the receiver
> and the SP is the sender of the notification.
>
> Do you think I am missing someting here ? Sorry for agreeing with you
> in v2 and silently changing it back without this actual discussion.
> Olivier raised the issue and then when I went back and looked at the
> spec, I realised why I had it this way from the beginning.

Thanks for the explanation, now I get it. My mistake was that I
thought that sender and receiver meant the sender and receiver of the
actual message being sent like with a direct request, it is using the
same register and the same wording after all. Instead, it means the
sender and receiver of an eventual notification, which of course is
the exact opposite.

Thanks,
Jens

2023-10-05 14:05:50

by Jens Wiklander

[permalink] [raw]
Subject: Re: [PATCH v3 07/17] firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface

On Wed, Oct 4, 2023 at 5:11 PM Sudeep Holla <[email protected]> wrote:
>
> On Wed, Oct 04, 2023 at 11:10:21AM +0200, Jens Wiklander wrote:
> > On Fri, Sep 29, 2023 at 04:02:56PM +0100, Sudeep Holla wrote:
> > > The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface
> > > to retrieve the list of endpoints that have pending notifications and
> > > must be run. A notification could be signaled by a sender in the secure
> > > world to a VM. The Hypervisor needs to determine which VM and vCPU
> > > (in case a per-vCPU notification is signaled) has a pending notification
> > > in this scenario. It must obtain this information through an invocation
> > > of the FFA_NOTIFICATION_INFO_GET.
> > >
> > > Add the implementation of the NOTIFICATION_INFO_GET interface
> > > and prepare to use this to handle the schedule receiver interrupt.
> > > Implementation of handling notifications will be added later.
> > >
> > > Signed-off-by: Sudeep Holla <[email protected]>
> > > ---
> > > drivers/firmware/arm_ffa/driver.c | 70 +++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 70 insertions(+)
> > >
> > > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > > index 02eedb7bc171..dfeeb751bebe 100644
> > > --- a/drivers/firmware/arm_ffa/driver.c
> > > +++ b/drivers/firmware/arm_ffa/driver.c
> > > @@ -602,6 +602,13 @@ static int ffa_notification_bitmap_destroy(void)
> > > (FIELD_PREP(RECEIVER_VCPU_MASK, (vcpu_r)) | \
> > > FIELD_PREP(RECEIVER_ID_MASK, (r)))
> > >
> > > +#define NOTIFICATION_INFO_GET_MORE_PEND_MASK BIT(0)
> > > +#define NOTIFICATION_INFO_GET_ID_COUNT GENMASK(11, 7)
> > > +#define ID_LIST_MASK_64 GENMASK(51, 12)
> > > +#define ID_LIST_MASK_32 GENMASK(31, 12)
> > > +#define MAX_IDS_64 20
> > > +#define MAX_IDS_32 10
> > > +
> > > static int ffa_notification_bind_common(u16 dst_id, u64 bitmap,
> > > u32 flags, bool is_bind)
> > > {
> > > @@ -673,6 +680,69 @@ static int ffa_notification_get(u32 flags, struct ffa_notify_bitmaps *notify)
> > > return 0;
> > > }
> > >
> > > +static void __do_sched_recv_cb(u16 partition_id, u16 vcpu, bool is_per_vcpu)
> > > +{
> > > + pr_err("Callback for partition 0x%x failed.\n", partition_id);
> > > +}
> > > +
> > > +static void ffa_notification_info_get(bool is_64b)
> > > +{
> > > + int idx, list, max_ids, lists_cnt, ids_processed, ids_count[MAX_IDS_64];
> > > + ffa_value_t ret;
> > > + u64 id_list;
> > > +
> > > + do {
> > > + invoke_ffa_fn((ffa_value_t){
> > > + .a0 = FFA_FN_NATIVE(NOTIFICATION_INFO_GET),
> > > + }, &ret);
> > > +
> > > + if (ret.a0 != FFA_FN_NATIVE(SUCCESS)) {
> >
> > The specification doesn't require a response using 64-bit SMCCC, it is
> > valid to respond using 32-bit SMCCC too.
> >
>
> Do you mean to say the we need to support 64b NOTIFICATION_INFO_GET
> returning 32b FFA_SUCCESS ? If so do we need to assume only 32bits are
> used in the result. As per the specification,
>
> "0xC4000061(FFA_FN64_SUCCESS): This function ID is used only if any result
> register encodes a 64-bit parameter."
>
> My question is what that means allowing 32bit FFA_SUCCESS here?

My bad, this is the one place where a 64-bit FFA_SUCCESS is more or
less required. I'll fix my side of things.

Thanks,
Jens

2023-10-05 14:30:18

by Jens Wiklander

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

Hi Sudeep,

On Wed, Oct 4, 2023 at 5:32 PM Sudeep Holla <[email protected]> wrote:
>
> On Wed, Oct 04, 2023 at 10:50:26AM +0100, Olivier Deprez wrote:
> > Hi Jens,
> >
> > > dst_id and drv_info->vm_id should be swapped.
> >
> > I'm curious about this because swapping like this actually makes hafnium
> > fail. Need to check from the spec.
>
> I did check after I had swapped this in v2(because I was convinced Jens) was
> correct and you reported the failure. Reading the spec again the other day,
> I got corrected myself and agreed with Olivier and my original
> implementation(v1) which matches this patch(v3).

I don't get it. The spec says for FFA_NOTIFICATION_BIND:
Sender and Receiver endpoint IDs.
– Bit[31:16]: Sender endpoint ID.
– Bit[15:0]: Receiver endpoint ID.
This is exactly the same as for instance FFA_MSG_SEND_DIRECT_REQ.

In ffa_msg_send_direct_req() you assign
src_dst_ids = PACK_TARGET_INFO(src_id, dst_id);

but here in ffa_notification_bind_common() you assign
src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);

Thanks,
Jens

2023-10-05 15:32:48

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Thu, Oct 05, 2023 at 08:57:26AM +0200, Jens Wiklander wrote:
> Hi Sudeep,
>
> On Wed, Oct 4, 2023 at 5:32 PM Sudeep Holla <[email protected]> wrote:
> >
> > On Wed, Oct 04, 2023 at 10:50:26AM +0100, Olivier Deprez wrote:
> > > Hi Jens,
> > >
> > > > dst_id and drv_info->vm_id should be swapped.
> > >
> > > I'm curious about this because swapping like this actually makes hafnium
> > > fail. Need to check from the spec.
> >
> > I did check after I had swapped this in v2(because I was convinced Jens) was
> > correct and you reported the failure. Reading the spec again the other day,
> > I got corrected myself and agreed with Olivier and my original
> > implementation(v1) which matches this patch(v3).

Well, I am not exactly sure what is the root cause for the confusion here:
My poor choice of variable names and their usage with this macro, or the
macro definition itself(I am not sure)

OR

The wordings in the specification

>
> I don't get it. The spec says for FFA_NOTIFICATION_BIND:
> Sender and Receiver endpoint IDs.
> – Bit[31:16]: Sender endpoint ID.
> – Bit[15:0]: Receiver endpoint ID.
> This is exactly the same as for instance FFA_MSG_SEND_DIRECT_REQ.
>

Not really as per my understanding of the specification.

> In ffa_msg_send_direct_req() you assign
> src_dst_ids = PACK_TARGET_INFO(src_id, dst_id);
>

Correct and if you look at the callsite, it is
ffa_msg_send_direct_req(drv_info->vm_id, dev->vm_id,...)

So the driver is the sender and the partition is the receiver. Probably
this is simpler.

> but here in ffa_notification_bind_common() you assign
> src_dst_ids = PACK_TARGET_INFO(dst_id, drv_info->vm_id);
>

A receiver(FF-A driver) must bind a non-framework notification to a
sender(SP) before the latter can signal the notification to the former.
Only the sender can ring these doorbells. A receiver uses the
FFA_NOTIFICATION_BIND interface to bind one or more notifications to the
sender.

So, based on this text(modified to refer sender and receiver in the driver
context) from the spec, my understanding is the driver is the receiver
and the SP is the sender of the notification.

Do you think I am missing someting here ? Sorry for agreeing with you
in v2 and silently changing it back without this actual discussion.
Olivier raised the issue and then when I went back and looked at the
spec, I realised why I had it this way from the beginning.

--
Regards,
Sudeep

2023-10-05 16:09:44

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH v3 03/17] firmware: arm_ffa: Implement the notification bind and unbind interface

On Thu, Oct 05, 2023 at 11:56:22AM +0200, Jens Wiklander wrote:
> On Thu, Oct 5, 2023 at 10:51 AM Sudeep Holla <[email protected]> wrote:

[...]

> > A receiver(FF-A driver) must bind a non-framework notification to a
> > sender(SP) before the latter can signal the notification to the former.
> > Only the sender can ring these doorbells. A receiver uses the
> > FFA_NOTIFICATION_BIND interface to bind one or more notifications to the
> > sender.
> >
> > So, based on this text(modified to refer sender and receiver in the driver
> > context) from the spec, my understanding is the driver is the receiver
> > and the SP is the sender of the notification.
> >
> > Do you think I am missing someting here ? Sorry for agreeing with you
> > in v2 and silently changing it back without this actual discussion.
> > Olivier raised the issue and then when I went back and looked at the
> > spec, I realised why I had it this way from the beginning.
>
> Thanks for the explanation, now I get it. My mistake was that I
> thought that sender and receiver meant the sender and receiver of the
> actual message being sent like with a direct request, it is using the
> same register and the same wording after all. Instead, it means the
> sender and receiver of an eventual notification, which of course is
> the exact opposite.
>

Thanks for the response. Glad we are on same page now with respect to this.

--
Regards,
Sudeep