[PATCH 0/5] RPMI REQUEST_FORWARD service group in OpenSBI

[Anup Patel]

Hi Marouene Boubakri,

On Mon, Sep 7, 2026 at 5:15 PM <marouene.boubakri at oss.nxp.com> wrote:
>
> From: Marouene Boubakri <marouene.boubakri at nxp.com>
>
> Hi all,
>
> I maintain the RISC-V port of OP-TEE. We are adding Management Mode
> support to it so that a non-secure supervisor can invoke MM services
> implemented in OP-TEE, and RPMI already defines the interface for that:
> MANAGEMENT_MODE (0x000B) on the calling side, and REQUEST_FORWARD
> (0x000D) on the side that serves the calls.

Very happy to see that NXP working towards supporting OP-TEE for RISC-V.

Oza (Qualcomm) from our side has already been posting a more generic
MPXY RPMI bridge driver with one destination MPXY channel for the
domain handling forwared RPMI requests and multiple source MPXY
channels for domains sending RPMI requests. To start with, Oza's series
currently support MANAGEMENT_MODE source channels but he also
has work-in-progress series to support upcoming TEE source channels.

(Please note the RPMI TEE service group is already available in the
latest RPMI v2.0 draft)

>
> The piece in between is missing. OpenSBI serves MANAGEMENT_MODE today
> only by passing MM_COMMUNICATE to a platform microcontroller over an RPMI
> mailbox (lib/utils/mpxy/fdt_mpxy_rpmi_mm.c), and there is no
> REQUEST_FORWARD support at all. When Management Mode runs in software on
> the application processor there is no mailbox and no microcontroller, and
> the SBI implementation itself has to be the forwarder. The OP-TEE side
> cannot proceed until that exists upstream, which is what this series
> adds.

RPMI MANAGEMENT_MODE is only a stop-gap protocol for TEE communication
since it is very simple and not designed for advance TEE communication which
support memory sharing and signalling.

>
> The RPMI v1.0 specification calls out this exact arrangement in the
> REQUEST_FORWARD service group: "This service group also allows an SBI
> implementation to forward RPMI request messages from one system-level
> partition (or domain) to another using the SBI MPXY extension."
>
> How it works: an RPMI request that arrives on one MPXY channel is queued
> and handed to software which pulls it off a second MPXY channel serving
> REQUEST_FORWARD, answers it, and completes it. The response comes back as
> the response of the original request. The queue and the REQUEST_FORWARD
> channel know nothing about MM; the MANAGEMENT_MODE channel of patch 5 is
> simply their first producer.
>
> The series touches include/sbi_utils/ and lib/utils/mpxy/ only. There is
> no change to lib/sbi/.
>
>   1  the RPMI v1.0 REQUEST_FORWARD service group defines
>   2  a prep patch moving the RPMI message protocol attributes out of the
>      mailbox header, so a channel driver with no mailbox behind it does
>      not have to include the mailbox headers. No functional change.
>   3  the forwarded message queue
>   4  the REQUEST_FORWARD channel driver
>   5  the MANAGEMENT_MODE channel that forwards through it
>
> Notes on what is deliberately not here:
>
> * REQFWD_ENABLE_NOTIFICATION reports RPMI_ERR_NOTSUPP. REQFWD_NEW_MESSAGE
>   is an RPMI notification message and SBI MPXY delivers those through an
>   MSI or an SSE event, neither of which is wired up for these channels, so
>   software polls REQFWD_RETRIEVE_CURRENT_MESSAGE.
> * Both channels are owned by the root domain, like every other MPXY
>   channel today. Making channel ownership follow the device tree needs the
>   platform domains to exist when MPXY drivers are probed, which is an init
>   order change worth its own discussion; it is not needed for the
>   forwarder itself.
>
> Tested on QEMU virt with two bare-metal S-mode payloads on two HARTs: one
> calls MM_COMMUNICATE with a buffer in the MM shared memory, the other
> serves the REQUEST_FORWARD channel and transforms it. The forwarded
> message is retrieved in three chunks (the channel MSG_MAX_LEN is set to 20
> bytes on purpose), a request outside the MM shared memory is refused, a
> response claiming more output than the request allowed is refused, a
> dropped request times out within MSG_COMPLETION_TIMEOUT, the late
> completion is refused, and the queue is usable afterwards.

It would be great if you can help review Oza's generic MPXY RPMI bridge
driver and preferrebly test it at your end as well so that we can make progress
faster.

Regards,
Anup