From c8e49504ddd5bb203aa31a877a85a7392ec1fdc7 Mon Sep 17 00:00:00 2001 From: J-Alves Date: Wed, 26 Oct 2022 11:00:28 +0100 Subject: [PATCH 1/2] docs(spm): s-el0 partition support update S-EL0 partitions already support indirect messaging and notifications so add that to supported features. Signed-off-by: J-Alves Change-Id: I08e04593653ba38a2b82395f6f2d3ca7b212d494 --- docs/components/secure-partition-manager.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst index 18d870bdc..9da66a8f6 100644 --- a/docs/components/secure-partition-manager.rst +++ b/docs/components/secure-partition-manager.rst @@ -1374,13 +1374,13 @@ S-EL0 partitions are required by the FF-A specification to be UP endpoints, capable of migrating, and the SPMC enforces this requirement. The SPMC allows a S-EL0 partition to accept a direct message from secure world and normal world, and generate direct responses to them. +All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not supported. -Memory sharing between and with S-EL0 partitions is supported. -Indirect messaging, Interrupt handling and Notifications are not supported with -S-EL0 partitions and is work in progress, planned for future releases. -All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not -supported. +Memory sharing, indirect messaging, and notifications functionality with S-EL0 +partitions is supported. +Interrupt handling is not supported with S-EL0 partitions and is work in +progress. References ========== From 53e3b385f02c3bfb64a51fe7f348c1bedec1902d Mon Sep 17 00:00:00 2001 From: J-Alves Date: Wed, 26 Oct 2022 13:46:37 +0100 Subject: [PATCH 2/2] docs(spm): ff-a v1.1 indirect message Update secure partition manager documentation to include FF-A v1.1 indirect messaging implementation. Signed-off-by: J-Alves Change-Id: Ifbca45347f775080ef98ac896d31650204318ba4 --- docs/components/secure-partition-manager.rst | 55 +++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst index 9da66a8f6..e4d5bfd2e 100644 --- a/docs/components/secure-partition-manager.rst +++ b/docs/components/secure-partition-manager.rst @@ -794,6 +794,8 @@ As part of the FF-A v1.1 support, the following interfaces were added: - ``FFA_SECONDARY_EP_REGISTER`` - ``FFA_MEM_PERM_GET`` - ``FFA_MEM_PERM_SET`` + - ``FFA_MSG_SEND2`` + - ``FFA_RX_ACQUIRE`` FFA_VERSION ~~~~~~~~~~~ @@ -827,7 +829,11 @@ regime as secure buffers in the MMU descriptors. When invoked from the Hypervisor or OS kernel, the buffers are mapped into the SPMC EL2 Stage-1 translation regime and marked as NS buffers in the MMU -descriptors. +descriptors. The provided addresses may be owned by a VM in the normal world, +which is expected to receive messages from the secure world. The SPMC will in +this case allocate internal state structures to facilitate RX buffer access +synchronization (through FFA_RX_ACQUIRE interface), and to permit SPs to send +messages. The FFA_RXTX_UNMAP unmaps the RX/TX pair from the translation regime of the caller, either it being the Hypervisor or OS kernel, as well as a secure @@ -969,6 +975,53 @@ secondary execution contexts. A secondary EC is first resumed either upon invocation of PSCI_CPU_ON from the NWd or by invocation of FFA_RUN. +FFA_RX_ACQUIRE/FFA_RX_RELEASE +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The RX buffers can be used to pass information to an FF-A endpoint in the +following scenarios: + + - When it was targetted by a FFA_MSG_SEND2 invokation from another endpoint. + - Return the result of calling ``FFA_PARTITION_INFO_GET``. + - In a memory share operation, as part of the ``FFA_MEM_RETRIEVE_RESP``, + with the memory descriptor of the shared memory. + +If a normal world VM is expected to exchange messages with secure world, +its RX/TX buffer addresses are forwarded to the SPMC via FFA_RXTX_MAP ABI, +and are from this moment owned by the SPMC. +The hypervisor must call the FFA_RX_ACQUIRE interface before attempting +to use the RX buffer, in any of the aforementioned scenarios. A successful +call to FFA_RX_ACQUIRE transfers ownership of RX buffer to hypervisor, such +that it can be safely used. + +The FFA_RX_RELEASE interface is used after the FF-A endpoint is done with +processing the data received in its RX buffer. If the RX buffer has been +acquired by the hypervisor, the FFA_RX_RELEASE call must be forwarded to +the SPMC to reestablish SPMC's RX ownership. + +An attempt from an SP to send a message to a normal world VM whose RX buffer +was acquired by the hypervisor fails with error code FFA_BUSY, to preserve +the RX buffer integrity. +The operation could then be conducted after FFA_RX_RELEASE. + +FFA_MSG_SEND2 +~~~~~~~~~~~~~ + +Hafnium copies a message from the sender TX buffer into receiver's RX buffer. +For messages from SPs to VMs, operation is only possible if the SPMC owns +the receiver's RX buffer. + +Both receiver and sender need to enable support for indirect messaging, +in their respective partition manifest. The discovery of support +of such feature can be done via FFA_PARTITION_INFO_GET. + +On a successful message send, Hafnium pends an RX buffer full framework +notification for the receiver, to inform it about a message in the RX buffer. + +The handling of framework notifications is similar to that of +global notifications. Binding of these is not necessary, as these are +reserved to be used by the hypervisor or SPMC. + SPMC-SPMD direct requests/responses -----------------------------------