Ken,

Our secure callback solution to this issue is working. I am just following up to understand what the SPM_IDLE concept is.

Alan

On Mar 20, 2020, at 4:34 AM, Ken Liu via TF-M tf-m@lists.trustedfirmware.org wrote:

 Hi Alan,

Looks like this is the still classic case, but unfortunately that there is no defined design at the current stage.

Heard you were working on an solution for this, and got some issues when non-secure preempts secure execution, since your scheduler works in thread mode so cannot update secure context while scheduling – please correct me if my understanding is wrong. Is this mail a follow up or another thread just focus on discussion of the cooperative scheduling document?

BR

/Ken

From: DeMars, Alan ademars@ti.com Sent: Friday, March 20, 2020 2:27 AM To: Ken Liu Ken.Liu@arm.com Cc: 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Subject: RE: SPM_IDLE

Ken,

Our use case is to support a “secure driver”:

1. A peripheral can only be accessed in secure mode. 2. The peripheral is configured and a hardware process is triggered within the peripheral. 3. When the process completes, a secure interrupt is triggered. 4. The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished.

Alan

From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE

Hi Alan,

It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable?

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m@lists.trustedfirmware.org' <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] SPM_IDLE

Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document:

https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui...

I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called.

Alan -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m