1. Preface
Learning with questions, some thoughts on exceptions/interrupts:
(1) In a large system like the one below, when the CPU is running in OP-TEE OS, and suddenly an interrupt (like a Bluetooth interrupt) that needs to be handled by the Linux Kernel arrives, what is the software and hardware flow at this moment?
(2) In the aforementioned large system, your Linux Kernel, OP-TEE OS, hypervisor, and ATF system all have exception vector tables. When an interrupt arrives, which system’s vector table does it jump to?
(3) What is interrupt nesting? How can interrupt nesting be supported? What is interrupt preemption? What is interrupt priority? What is runtime interrupt priority?
(4) What is FIQ? What is the relationship between FIQ and IRQ?
(5) When an interrupt arrives, how does it jump to the vector table? What routing does it go through?
(6) After you invoke the SVC/HVC/SMC instruction, how does the CPU jump to the expected target address?
(7) What synchronous exceptions exist, what asynchronous exceptions exist, which priorities are the same, and which priorities are different?
(8) Where is the exception vector table stored? Why do some people say it is stored at 0x00000000?
(9) What is meant by “interrupt is asserted”? What is “interrupt is taken”? What does “PE acknowledge this interrupt” mean? What do target and routing mean? What about target from and target to?
As a low-level security engineer and a frontline support customer FAE, my work involves many modules such as TF-A, TEE, Linux Kernel, hypervisor, SPM, etc. The CPU (or PE or core or PC) will jump between these modules. Since most of this code is open source and written by others, often there is no need to look at the underlying design principles. However, as an FAE, I often encounter the soul-searching questions from customers. To provide a professional feel to customers, I have to understand the underlying deep principles. Additionally, sometimes when encountering performance-related issues, not understanding the underlying design principles may hinder the analysis of such problems.
I am not an expert or a big shot. I have just read some ARM documentation and combined it with my understanding to summarize the following article. Of course, I base everything on official materials during my summarization, trying not to make unfounded claims.
Finally, I hope this series of articles can be helpful to everyone. Study hard, and keep improving, comrades.
Note:
- This series is based on the ARMv8-Aarch64/ARMv9 architecture, Linux Kernel 5.10, OP-TEE 3.16, TF-A 2.5
-
Most of the content comes from ARM’s official documentation, with very little based on speculation, plus some of my own understanding…
2. Learning Objectives
- Understand the entire data flow of interrupts, from peripheral to GIC to core and then to operating system software
- Understand how interrupts are generated, marked, routed, the interrupt master, and how the operating system handles interrupts
- Understand what hardware automatic behaviors occur after an interrupt is generated from the peripheral, what are the architecturally recommended software processes, and the handling processes in various operating system software
- This series of articles mainly discusses points 3 and 4 in the diagram, including the following articles: 01-Detailed Explanation of ARMv8/ARMv9 Interrupts – Preface 02-Detailed Explanation of ARMv8/ARMv9 Interrupts – Hardware Basics 03-Detailed Explanation of ARMv8/ARMv9 Interrupts – Interrupt Example Display (excluding virtualization part) 04-Detailed Explanation of ARMv8/ARMv9 Interrupts – Interrupt Example Display (virtualization part) 05-Detailed Explanation of ARMv8/ARMv9 Interrupts – OP-TEE Runtime Handling of a REE (Linux) Interrupt – Code Guide 06-Detailed Explanation of ARMv8/ARMv9 Interrupts – Software Part – Introduction to Linux Kernel Interrupt Related Software