9ca7a421 | 28-May-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context
The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It resul
firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context
The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings:
| BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20
To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness.
This change resolves warnings from lockdep about potential sleep in atomic context.
Cc: Jens Wiklander <jens.wiklander@linaro.org> Reported-by: Jérôme Forissier <jerome.forissier@linaro.org> Closes: https://github.com/OP-TEE/optee_os/issues/7394 Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-3-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
27e850c8 | 28-May-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Move memory allocation outside the mutex locking
The notifier callback node allocation is currently done while holding the notify_lock mutex. While this is safe even if memory all
firmware: arm_ffa: Move memory allocation outside the mutex locking
The notifier callback node allocation is currently done while holding the notify_lock mutex. While this is safe even if memory allocation may sleep, we need to move the allocation outside the locked region in preparation to move from using muxtes to rwlocks.
Move the memory allocation to avoid potential sleeping in atomic context once the locks are moved from mutex to rwlocks.
Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-2-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
cc0aac7c | 17-Jan-2025 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mappi
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
c67c2332 | 23-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or more vCPU ID. The count includes all of them.
Fix the issue by skipping the first/partition ID so that only the list of vCPU IDs are processed correctly for a given partition ID. The first/ partition ID is read before the start of the loop.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
3e282f41 | 21-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value.
Since the return value from the
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value.
Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NO_DATA.
Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
cecf6a50 | 21-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value.
Since the return valu
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value.
Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NOT_SUPPORTED.
Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions.
Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
9472fe20 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
Currently it is assumed that the driver always calls ffa_notification_get() at the NS physical FF-A instance to requ
firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
Currently it is assumed that the driver always calls ffa_notification_get() at the NS physical FF-A instance to request the SPMC to return pending SP or SPM Framework notifications. However, in order to support the driver invoking ffa_notification_get() at virtual FF-A instance, we need to make sure correct bits are enabled in the bitmaps enable flag.
It is expected to have hypervisor framework and VM notifications bitmap to be zero at the non-secure physical FF-A instance.
Message-Id: <20250217-ffa_updates-v3-19-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
be61da93 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
A partition can implement multiple UUIDs and currently we successfully register each UUID service as a FF-A device. How
firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
A partition can implement multiple UUIDs and currently we successfully register each UUID service as a FF-A device. However when adding the same partition info to the XArray which tracks the SRI callbacks more than once, it fails.
In order to allow multiple UUIDs per partition to register SRI callbacks the partition information stored in the XArray needs to be extended to a listed list.
A function to remove the list of partition information in the XArray is not added as there are no users at the time. All the partitions are added at probe/initialisation and removed at cleanup stage.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-18-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
285a5ea0 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Add support for handling framework notifications
Currently FF-A specification defines only one framework notification: RX buffer full notification. This notification is signaled b
firmware: arm_ffa: Add support for handling framework notifications
Currently FF-A specification defines only one framework notification: RX buffer full notification. This notification is signaled by the partition manager during transmission of a partition message through indirect messaging to,
1. Notify an endpoint that it has a pending message in its Rx buffer. 2. Inform the message receiver’s scheduler via the schedule receiver interrupt that the receiver must be run.
In response to an FFA_MSG_SEND2 invocation by a sender endpoint, the framework performs the following actions after the message is copied from the Tx buffer of the sender to the Rx buffer of the receiver:
1. The notification is pended in the framework notification bitmap of the receiver. 2. The partition manager of the endpoint that contains receiver’s scheduler pends the schedule receiver interrupt for this endpoint.
The receiver receives the notification and copies out the message from its Rx buffer.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-17-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
c10debfe | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Add support for {un,}registration of framework notifications
Framework notifications are doorbells that are rung by the partition managers to signal common events to an endpoint.
firmware: arm_ffa: Add support for {un,}registration of framework notifications
Framework notifications are doorbells that are rung by the partition managers to signal common events to an endpoint. These doorbells cannot be rung by an endpoint directly. A partition manager can signal a Framework notification in response to an FF-A ABI invocation by an endpoint.
Two additional notify_ops interface is being added for any FF-A device/ driver to register and unregister for such a framework notifications.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-16-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
a3d73fe8 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
Currently, we store the type of the notification in the notifier_cb_info structure that is put into the hast list to id
firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
Currently, we store the type of the notification in the notifier_cb_info structure that is put into the hast list to identify if the notification block is for the secure partition or the non secure VM.
In order to support framework notifications to reuse the hash list and to avoid creating one for each time, we need store the ffa_device pointer itself as the same notification ID in framework notifications can be registered by multiple FF-A devices.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-15-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
07b760e7 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Refactoring to prepare for framework notification support
Currently, the framework notifications are not supported at all. handle_notif_callbacks() doesn't handle them though it i
firmware: arm_ffa: Refactoring to prepare for framework notification support
Currently, the framework notifications are not supported at all. handle_notif_callbacks() doesn't handle them though it is called with framework bitmap. Make that explicit by adding checks for the same.
Also, we need to further classify the framework notifications as Secure Partition Manager(SPM) and NonSecure Hypervisor(NS_HYP). Extend/change notify_type enumeration to accommodate all the 4 type and rejig the values so that it can be reused in the bitmap enable mask macros.
While at this, move ffa_notify_type_get() so that it can be used in notifier_hash_node_get() in the future.
No functional change.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-14-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
9982cabf | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
In order to keep the uniformity, just move the ffa_partitions_cleanup() before it's first usage and drop the unnecessary
firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
In order to keep the uniformity, just move the ffa_partitions_cleanup() before it's first usage and drop the unnecessary forward declaration.
No functional change.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-13-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
efff6a7f | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Reject higher major version as incompatible
When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with differ
firmware: arm_ffa: Reject higher major version as incompatible
When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"), we only addressed firmware versions that have higher minor versions compared to the driver version which is should be considered compatible unless the firmware returns NOT_SUPPORTED.
However, if the firmware reports higher major version than the driver supported, we need to reject it. If the firmware can work in a compatible mode with the driver requested version, it must return the same major version as requested.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
9fac08d9 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver
The basic and mandatory features of FF-A v1.2 are all supported now. The driver supported version can be bumped from v1.1 to v1.2
Teste
firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver
The basic and mandatory features of FF-A v1.2 are all supported now. The driver supported version can be bumped from v1.1 to v1.2
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-11-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
910cc1ac | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Add support for passing UUID in FFA_MSG_SEND2
FF-A v1.2 introduces UUID field in partition message header used in FFA_MSG_SEND2 to enable partitions/endpoints exposing multiple UU
firmware: arm_ffa: Add support for passing UUID in FFA_MSG_SEND2
FF-A v1.2 introduces UUID field in partition message header used in FFA_MSG_SEND2 to enable partitions/endpoints exposing multiple UUIDs.
Add the support for passing UUID in FFA_MSG_SEND2.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-10-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
46dcd68a | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus an
firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules").
The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices. Now that there are 2 distinct modules, if the core driver is unloaded and reloaded, it will end up adding duplicate FF-A devices as the previously registered devices weren't unregistered when we cleaned up the modules.
Fix the same by unregistering all the FF-A devices on the FF-A bus during the cleaning up of the partitions and hence the cleanup of the module.
Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules") Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-8-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
2f622a8b | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Handle the presence of host partition in the partition info
Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as par
firmware: arm_ffa: Handle the presence of host partition in the partition info
Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as part of the response to PARTITION_INFO_GET from the firmware. However, there are few platforms that prefer to present the same in the list of partitions. It is not manadatory but not restricted as well.
So handle the same by making sure to check the presence of the host VM ID in the XArray partition information maintained/managed in the driver before attempting to add it.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
3c3d6767 | 17-Feb-2025 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_ffa: Refactor addition of partition information into XArray
Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional cha
firmware: arm_ffa: Refactor addition of partition information into XArray
Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional change.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-6-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
7bc0f589 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of tes
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test infrastructure and tools.
In order to support full stack, we need to take small steps in getting the support for big-endian kernel added slowly. This change fixes the support in __ffa_partition_info_regs_get() so that the response from the firmware are converted correctly as required. With this change, we can enumerate all the FF-A devices correctly in the big-endian kernel if the FFA_PARTITION_INFO_REGS_GET is supported.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-5-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
f94ebb72 | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test inf
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test infrastructure and tools.
In order to support full stack, we need to take small steps in getting the support for big-endian kernel added slowly. This change fixes the support in __ffa_partition_info_get() so that the response from the firmware are converted correctly as required. With this change, we can enumerate all the FF-A devices correctly in the big-endian kernel.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-4-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
8768972c | 17-Feb-2025 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Align sync_send_receive{,2} function prototypes
Currently ffa_sync_send_receive2() takes UUID as a separate parameter instead of using the one available in ffa_device structure.
firmware: arm_ffa: Align sync_send_receive{,2} function prototypes
Currently ffa_sync_send_receive2() takes UUID as a separate parameter instead of using the one available in ffa_device structure.
Change the prototype of ffa_sync_send_receive2() to align with the ffa_sync_send_receive() and use ffa_device->uuid.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-3-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|