[TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler

Hi Manish,

Just following up on your comment below. Are you planning to provide guidance as to which PSCI calls should have NS interrupts masked? Are these changes that should go in the mainline TF-A repo, or do you believe they are specific to our use case?

Thanks, Brian

From: Manish Pandey2 via TF-A tf-a@lists.trustedfirmware.org Sent: Friday, November 10, 2023 11:31 AM To: tf-a@lists.trustedfirmware.org; Ethridge, Caleb Caleb.Ethridge@analog.com Subject: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler

[External]

Hi Caleb,

The quick answer to your query is to mask the NS interrupts in BL31 (option a), You should not remove the callback to OPTEE as it may need to do its own state maintained before system RESET.

There are other scenarios in PSCI (e.g. CPU power down) path which need to consider disabling NS interrupts before invoking Secure world hooks, will provide further analysis on those later.

Thanks Manish Pandey

________________________________ From: Caleb Ethridge via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 10 November 2023 15:12 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Handling of normal world interrupts with BL31 PSCI handler

Hello,

If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted.

In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/ps...https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/psci_system_off.c*L44__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHyWqcCFuQ$ https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/sp...https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firmware/blob/master/services/spd/opteed/opteed_pm.c*L233__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHypZWQwUQ$

When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-se...https://urldefense.com/v3/__https:/optee.readthedocs.io/en/3.16.0/architecture/core.html*deliver-non-secure-interrupts-to-normal-world__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHzqKZ6_0Q$ When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#L...https://urldefense.com/v3/__https:/github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c*L308__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHwH0cQx8g$). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE).

If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c*L140__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHwHJcYAAQ$ https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S*L96__;Iw!!A3Ni8CS0y2Y!7wdssXjEhDud9Tm5QRek7Mw71eVJJfoimjH1u-u9fLXfaoLqv1ECsW3KakFsaMwnp3xZzyiBgwAyngBZMHxqZFTGrA$

Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context

Which option do you suggest? Or are we missing an important detail here?

Thanks,

Caleb -- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org