The teacher is talking about ARM course: Xiao Ming, could you tell me the difference between interrupt and missing page interrupt?

Xiaoming: They are not born of the same mother

Teacher: Xiao Ming, get out…

Yesterday we talked about missing page interrupts in interrupt handlers. We only discussed the do_page_fault() kernel processing path, which basically covers the major and most difficult scenarios, For the simple do_translation_fault()/do_sect_fault() path, we thought the code was simple and easy to understand, so we ignored it.

Let’s take a look at exception handling on ARM V7. To learn more about exception handling on ARM V7, we need to turn to ARM’s official manual. The ARM V8 manual has a total of 6,666 pages, but don’t worry. ARM V8, we’ll talk to you about it later.

01

Open the ARM V7 manual and you’ll find exception handling in chapter B1.8. I’ll introduce you to the anomaly direction scale at the beginning.

It should be noted that ARM’s chip manual introduces several modes together, such as Hyp mode, Monitor mode, Secure mode and non-secure mode, which will make beginners look a bit confused. It would be better to separate these modes. Assuming we focus only on scenarios where the Linux kernel is running, let’s focus on non-secure mode. This shows that exception handling is mainly prefetch abort, data abort, and undefined abort. In fact, data abort and prefetch abort are related to page miss interrupts. \

There is also the problem of placing the vectorizer. The traditional vectorizer can be placed at 0x0 or 0xFFFF_0000. Of course, by setting the V field of the SCTL register, the position of the vectorizer can be arbitrarily placed according to the requirements of the program.

Then chapter B.1.8.3 shows what the ARM processor does if an exception occurs.

The image above looks like this when translated by Uncle Ben:

  1. Hardware, you have to decide which exception to fire first, right? Abort or data or undefined, this shouldn’t be our programmer’s cue
  2. Save the SPSR register from the CPSR at the scene where the exception occurred to the exception mode
  3. Save the return address to the LR register
  4. Set the cpsr. M domain to the appropriate mode and switch to that mode. Set the corresponding mask bits to prevent exceptions from nesting
  5. PC points to the corresponding place on the vector table, and then go

Run in exception mode when an exception occurs. ARM is strange, each mode has its own stack, just like interrupts. Usually the hardware will bring the exception mode for you, but the stack size of the exception mode is limited, there is no way to store all the context, so what do you do? Usually the software wobbles in exception mode and then goes to SVC mode.

Git tree runningLinuxkernel_4.0 (” runningLinuxkernel_4.0 “) is abort to vector_dabt. (arch/arm/kerne/entry-armv.S)

In 1188 lines of code above, a Vector_stub is a macro. Why is the last parameter of this macro 8 and the last parameter of vector_irq 4? We still have to rely on the ARM V7 manual, which is our bread and bread. In chapter B1.8.3, there is such a table, which means that at the time of each exception, the VALUE stored in the LR register is the address of the point at which the exception occurred with an offset, due to pipeline reasons. But the LR saved in OS needs to subtract this offset, as we can see in the vector_stub macro code.

The vector_stub macro code is as follows:

It’s much easier to understand it by roughly dividing it into four parts. The first part subtracted the offset to get the real LR return address. The second part saved the LR and SPSR registers to the exception stack when the exception occurred. The third part switched to SVC mode. Then jump to _dabt_svc and _dabt_usr respectively.

A detailed explanation of each line of the vector_stub macro can be found on page 621 of Running Linux Kernel.

The following uses _data_svc as an example.

Svc_entry and svc_exit are macros. See Section 5.1.4 running Linux Kernel for code analysis.

The ARM V7 processor, it ends up in v7_early_abort assembly function,

What do lines 16 and 17 mean?

There are two registers involved, FSR and FAR. Let’s look at chapter B3.13.1 of the chip manual first, which explains how we can know what happened when an exception occurred. Because the hardware can accurately get the cause and address of the exception, but we do not know, so we need to tell us through the register, right?

As I told you, there is a register called FSR that holds the exception status information, and a register called FAR that holds the address where the exception occurred. Where are these two registers described? See sections B4.1.51 and B4.1.52 for a detailed description of these two registers.

BIT[0~3]; BIT[10]; BIT[0~3]; The code looks like this.

At least we’re on the same page. So what’s the use of the FS field? If you look at chapter B3.13.3 of the manual, there is a table describing the use of the FS field.

This table defines many types of page missing exceptions, such as Translation Fault, Access Fault, Domain Fault, Permission Fault, etc.

The do_DataAbort() function looks like this, and you can focus on line 547, where fsr_fs() was mentioned earlier. Fsr_info is defined as a table.

Look up the table through the FS field of the FSR register and jump to the corresponding handler.

You can check the code against the FS table to see when it is do_translation_fault()/do_sect_fault() and when it is do_page_fault.

There is also an exception in ARM called prefetch abort. The code path and principle are similar. You can read the ARM V7 manual and the corresponding code.

Running Linux community adhere to the original article, original, never reproduced! If you like, remember to tip and forward, thank you!

Preview: Running Linux community season 2 “Processes, Locks and interrupts in one”, the primary and the flagship will be launched soon, stay tuned!