lists.trustedfirmware.org
Sign In
Sign Up
Sign In
Sign Up
Manage this list
×
Keyboard Shortcuts
Thread View
j
: Next unread message
k
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
2024
May
April
March
February
January
2023
December
November
October
September
August
July
June
May
April
March
February
January
2022
December
November
October
September
August
July
June
May
April
March
February
January
2021
December
November
October
September
August
July
June
May
April
March
February
January
2020
December
November
October
September
August
July
June
May
April
March
February
January
2019
December
November
October
September
August
July
June
May
April
March
February
January
2018
December
List overview
Download
TF-A
February 2024
----- 2024 -----
May 2024
April 2024
March 2024
February 2024
January 2024
----- 2023 -----
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
----- 2022 -----
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
----- 2021 -----
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
----- 2020 -----
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
----- 2019 -----
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
----- 2018 -----
December 2018
tf-a@lists.trustedfirmware.org
14 participants
21 discussions
Start a n
N
ew thread
Handling of normal world interrupts with BL31 PSCI handler
by caleb.ethridge@analog.com
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/p…
https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s…
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-s…
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#…
). 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#L140
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96
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
3 months, 1 week
6
11
0
0
← Newer
1
2
3
Older →
Jump to page:
1
2
3
Results per page:
10
25
50
100
200