Hi all,
When TF-M RPC callbacks were introduced to support multi-core mailbox handling, typically only a single mailbox interrupt source was available on a multi-core system.
Therefore, in the initial design, RPC callback handle_req(void) doesn't pass any information of mailbox interrupt source to platform mailbox drivers.
Recently, some platforms, such as RSE based ones, consists of multiple mailbox interrupt sources.
I notice that those platforms fetch and parse mailbox messages in their mailbox IRQ handlers. It can take quite a long time in IRQ handlers and doesn't get full benefits from Second-Level Interrupt Handling.
Due to the limitation of RPC callback handle_req(void), those platforms are unable to move mailbox message handling to threaded NS Agent Mailbox SP context.
I'd propose to add a new RPC callback handle_req_irq_src(irq_src) to pass mailbox interrupt source information to platform drivers. With this information, platform drivers can identify the source and select the corresponding handler to fetch, parse and dispatch mailbox messages in NS Agent Mailbox SP context, instead of in IRQ handlers.
If platform owners are all satisfied with this new RPC callback, I also wonder if it can replace the existing handle_req() in future, assumed no backward compatible issues are raised.
Please can you review the patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34317/1?
Any comment is welcome. Thank you.
Best regards,
David Hu
Hi All,
I pushed for initial testing and review a series of patches to support the Scheduling-NSPE Hybrid Platform Solution (aka Solution-2).
A "Hybrid Platform" is an extension of the MULTICORE case where applications also run in the NS-side of the core that hosts TF-M SPE.
Patches can be found at this gerrit topic (hybrid-plat-nspe): https://review.trustedfirmware.org/q/topic:%22hybrid-plat-nspe%22.
All the patches are Request-For-Comments (RFC) and the community is welcome to provide feedback on such changes/proposal.
The "Hybrid Platform" support coming to TF-M has been discussed a few times in the past and slides and recordings are available in the technical forum past events: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/.
This presented solution follows the main ideas presented in the past.
However, since the last presentations, some adjustments have been done, in particular around:
- naming: we won't use numbers for solutions, like Sol.1, 2 etc, but instead we name them: _SPE, _NSPE etc, to make immediately clear the use-case.
- "simple first" approach: we aim to provide a "simple" solution in the attempt to provide an initial reference and keep the core code readable, compact and testable. If there are significant use-cases to be included, please share your feedback and we'll find a best solution.
Kindly expect some changes on these proposed patches above while I rebase, perform some other tests and need to refactor some portions.
Expected timeline for Hybrid Platform Solution:
- SPE-support: already merged into mainline
- NSPE-support (this series above), merge within two months (end of Feb-25), provided that there will be no disruptive changes
- BALANCED-support: a new set will be available around the middle of 2025 (subject to change).
Many thanks in advance and happy New Year.
Best regards,
Nicola
Nicola Mazzucato (7):
[RFC 1/7] SPM: tfm_rpc: Add `process_new_msg handler`
[RFC 2/7] tfm_spe_mailbox: Add `mailbox_process_new_msg` handler
[RFC 3/7] ns_agent_mailbox: Add NS_AGENT_MBOX_PROCESS_NEW_MSG_SIGNAL aux service
[RFC 4/7] SPM: backend_ipc: Conditionally assert MBOX signal on SCHED_TYPE
[RFC 5/7] SPM: tfm_multi_core: Record and clear mailbox IRQ via multi_core API
[RFC 6/7] docs: hybrid_platform: Add documentation
[RFC 7/7] Config Base for Hybrid Platform
Nicola Mazzucato (he/him/his) | CE-Software Group | Arm
110 Fulbourn Rd, CB1 9NJ, Cambridge UK
At Arm we work flexibly and globally, if you receive this email outside of your usual working hours please do not feel that you have to respond immediately.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
