Hi Ashu, The proposal is good and covers most of the cases while a NS and S communication channel is available. And I think below part is going to be considerate before we create design docs to follow this rules:
- Leave the NSPE SPM_IDLE case handling as implementation defined instead of involving IRQ to bring more complexity. NSPE could just yield but SPE needs to support a bit asynchronization -- that is not a big fair compare to IRQ communication.
- The rules rely on the NSPE/SPE communication channel but for if NSPE has no use/misuse this channel SPE should detect the problem and panic NSPE, this is also can to be implemented.
Most of the interrupt priority related rules can be done with hardware setting. The priority of secure partition with IRQ needs to be considerate while partitions designing since in IPC model scheduler decides who should go based on partition priority.
Let's see if we can find more cases while implementing.
BR
-Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ashutosh Singh via TF-M Sent: Tuesday, April 30, 2019 7:06 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] TF-M Cooperative Scheduler Design - Scheduling Rules
Hi,
This is a proposal that introduces scheduling rules in TF-M. Introduction: On ArmV8-M CPUs, NSPE and SPE share the same physical processing element(PE). A TF-M enabled system need to be able to handle asynchronous events (interrupts) regardless of current security state of the PE; and that may lead to scheduling decisions. This introduces significant complexity into TF-M. To keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and SPE, following set of rules are imposed on the TF-M scheduler design. https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/
Feedback welcome!
Thanks, Ashu
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m