Hi Jens,
On 10/8/2026 5:15 PM, Jens Wiklander wrote:
Hi Amir,
On Tue, Oct 6, 2026 at 2:39 AM Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com wrote:
This series adds an RPMI backend to the OP-TEE driver for RISC-V. It builds on the separately posted RPMI TEE transport series [1], which provides service discovery, synchronous calls, memory parcels and asynchronous signals.
This revision is effectively a full rewrite of the original RFC. The generic RPMI transport has been separated from the OP-TEE backend, and the backend has been reworked around the service bus and a new OP-TEE control ABI.
Unlike v1, the OP-TEE backend no longer manages SBI MPXY mailbox channels or implements RPMI TEE service-group operations directly. It binds to the OP-TEE service UUID on the RPMI TEE bus and uses the transport's public operations. No additional OP-TEE device-tree node is required.
The backend reuses the common OP-TEE session, shared-memory, argument cache, call queue and RPC infrastructure. Shared memory is represented by RPMI parcel IDs and nonces. Yielding calls pass command and RPC buffer ranges within a parcel and resume suspended execution using an opaque token returned by OP-TEE.
The OP-TEE control ABI uses fixed-width little-endian messages carried in TEE_CALL payloads rather than reproducing FF-A's register-based message layout. Asynchronous notifications use an allocated TEE-to-REE signal as a bottom-half doorbell, while ordinary logical notifications continue through the common RPC path.
Matching OP-TEE OS support for this ABI has not yet been implemented. This remains an RFC for review of the backend integration and the Linux-to-OP-TEE protocol.
[1] RPMI TEE transport dependency: https://lore.kernel.org/op-tee/20260928-riscv-rpmi-tee-abi-v1-0-04908b81d885...
Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
Changes in v2:
- Effectively rewrite the backend around the separately posted RPMI TEE transport and a new OP-TEE control ABI.
- Remove backend-owned per-hart mailbox channels and the OP-TEE-specific device-tree binding.
- Replace the register-like control payload with fixed-width messages, explicit command/RPC buffer ranges and opaque resume tokens.
- Add a parcel-reference parameter layout carrying the parcel ID, nonce, and 64-bit offset and size without changing parameter size.
- Make argument-offset support part of the baseline ABI and retain the common shared argument cache.
- Use a transport-allocated signal for asynchronous bottom-half notifications.
- Link to v1: https://lore.kernel.org/r/20260912-rpmi-tee-service-grp-dev-v1-0-1d1d35c2a85...
Amirreza Zarrabi (8): tee: optee: allow RPMI transport builds on RISC-V tee: optee: define the RPMI control and parcel-reference ABI tee: optee: add RPMI shared-memory and parameter support tee: optee: add RPMI dynamic shared-memory pool tee: optee: add RPMI RPC handling tee: optee: execute yielding RPMI calls tee: optee: bind RPMI services and negotiate backend capabilities tee: optee: support RPMI asynchronous notification doorbells
drivers/tee/Kconfig | 3 +- drivers/tee/optee/Kconfig | 3 +- drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 2 + drivers/tee/optee/core.c | 10 +- drivers/tee/optee/optee_msg.h | 38 +- drivers/tee/optee/optee_private.h | 54 +- drivers/tee/optee/optee_rpmi.h | 234 ++++++++ drivers/tee/optee/rpmi_abi.c | 1059 +++++++++++++++++++++++++++++++++++++ 9 files changed, 1389 insertions(+), 15 deletions(-)
The rpmi changes in the optee driver harmonize quite well with the rest of the driver, but there are two things I'd like fixed:
- avoid <linux/cleanup.h> macros. They are distracting.
- use rc for the trivial int ERRNO values.
I'll make these changes.
I would be great with a QEMU-based end-to-end prototype to demonstrate that the ABI works.
The OP-TEE side implementation is nearly complete. I'll incorporate your comments here and update the OP-TEE code accordingly. I haven't started the OpenSBI changes yet. Getting a QEMU-based end-to-end prototype working is my first priority before moving the series out of RFC.
Apologies for the obvious oversights and bugs in this version. So far, I've only compile-tested the code; it still needs end-to-end validation.
More comments to come in the individual patches.
Thanks, Jens, for the early comments and feedback. They are very helpful in shaping the final code and guiding the direction of the implementation.
Best regards, Amir
Cheers, Jens