Outage of Linux

Reference http://www.yesky.com/20010813/192117.shtml

Structured programming Thought: program = data structure + algorithm. The data structure embodies the architecture of the entire system, so it is often a good starting point for code analysis, especially for Linux kernel analysis.

For example, the Process Control block structure analysis clearly, on the process has a basic grasp;

For example, the page directory structure and page table structure to understand, two-level virtual storage mapping and memory management is almost mastered.

In order to reflect the gradual thinking, in this I will use the Linux interrupt mechanism processing to introduce this method.

First of all, it must be pointed out that: here, the generalized interruption of the middle finger, which refers to all the control transfer through IDT mechanism and processing; It covers the following common meanings: Interrupts, exceptions, masked interrupts, unshielded interrupts, hard interrupts, soft interrupts ...

I, hardware-provided interrupt mechanism and conventions

one. Interrupt vector addressing:

The hardware provides an entry for 256 service programs to break into, i.e. interrupt vectors;

The implementation mechanism of interrupt vectors in protected mode is the interrupt descriptor Idt,idt position determined by IDTR, IDTR is a 48-bit register, the high 32 bits are IDT's base address, and the lower 16 bits are the limits of IDT (usually 2k=256*8);

IDT contains 256 interrupt descriptors, corresponding to 256 interrupt vectors, 8 bits per interrupt descriptor, and the structure of a

two. Exception handling mechanism:

　　Intel retains the 0-31 interrupt vector to handle exception events : When an exception is generated, the processor automatically transfers control to the appropriate handler's entry, the exception handler is provided by the operating system, and the interrupt vector and exception events correspond to table one:

Table I, interrupt vector and Exception event correspondence table

Interrupt Vector number	Exception events	Linux processing program
0	Division Error	Divide_error
1	debugging exceptions	Debug
2	NMI Interrupt	Nmi
3	Single byte, int 3	Int3
4	Overflow	Overflow
5	Boundary monitoring interrupted	Bounds
6	Invalid operation code	Invalid_op
7	Device Not available	Device_not_available
8	Double fault	Double_fault
9	Coprocessor Segment Overflow	Coprocessor_segment_overrun
10	Invalid TSS	Incalid_tss
11	Missing segment Interruption	Segment_not_present
12	Stack exception	Stack_segment
13	General Protection exceptions	General_protection
14	Page exception	Page_fault
15		Spurious_interrupt_bug
16	Coprocessor Error	Coprocessor_error
17	Alignment Check Interrupt	Alignment_check

II. Interrupt processing for Linux

The hardware interrupt mechanism provides 256 portals, which are 256 interrupt descriptors (corresponding to 256 interrupt vectors) contained in IDT.

　　The 0-31 interrupt vector is reserved by Intel Corporation for handling unusual events and cannot be used for other purposes. For this 0-31 interrupt vector, the operating system simply provides an exception handler, and when an exception is generated, the processor automatically transfers control to the appropriate handler's entry and runs the appropriate handler, and in fact, for the 32 interrupt vectors that handle the exception, This version (2.2.5) of Linux only provides a handler for the 0-17 interrupt vector, which corresponds to the table one, the interrupt vector, and the Exception event table, which means that the number 17-31 interrupt vector is unused.

Now that the number 0-31 interrupt vector has been retained, then there are 32-255 total 224 interrupt vectors available. How are the 224 interrupt vectors allocated? In this version (2.2.5) of Linux, except that 0x80 (Syscall_vector) is used as the total entry for system calls , the others are used on external hardware interrupt sources, including 15 IRQ for programmable interrupt Controller 8259A; When no config_x86_io_apic is defined, the other 223 (except 0x80) interrupt vectors are used only 15 from number 32nd and the other 208 are unused.

The settings for the entry of these interrupt service programs are described in detail below.

A Related Data structures

1. Interrupt Descriptor Table IDT: That is, interrupt vector tables, which are equivalent to an array that holds the entry for each interrupt service routine. (Detailed description See figure I, interrupt description format )
2. Data structures related to hard interrupts:

My understanding: Handler refers to which processor to handle this, and the action is the actual processing routine. The action will be handed to handler for processing. I don't know, right.

Http://www.yesky.com/20010813/192117_2.shtml

three. Bottom_half processing mechanism

In this version (2.2.5) of Linux, the interrupt handler is conceptually divided into the upper half (top half) and the lower half (bottom half), and the processing of the upper half of the interrupt occurs immediately, but the lower half, if any, delays execution. The kernel handles the upper and lower halves as separate functions, and the upper half determines whether the lower part of the section needs to be executed. The part that must be executed immediately must be in the upper part, while the part that can be postponed may belong to the lower part.

So why is it divided into two parts?

• One reason is to minimize the total delay time of the interrupt . The Linux kernel defines two types of interrupts, fast and slow, and one difference between them is that a slow interrupt itself can be interrupted, and a fast interrupt cannot. Therefore, when processing a fast interrupt, if there are other interrupts arriving, either fast or slow interrupts, they must wait. To handle these other interrupts as quickly as possible, the kernel needs to defer processing to the lower half as much as possible.
• Another reason is that when the kernel executes the upper half, the special IRQ being serviced will be banned by the programmable interrupt controller, so that other devices connected to the same IRQ will only be able to issue IRQ requests until the interrupt processing has been processed. After adopting the bottom_half mechanism, the part that does not need to be processed immediately can be disposed in the lower part, thus speeding up the response speed of the processor to the interrupt request of the external device.
• Another reason is that the lower half of the handler can also contain actions that are not required to be handled by each interrupt , and the kernel can be processed one time after a series of device interrupts. In this case, it is a waste to perform an operation that is not necessary each time, and with the bottom_half mechanism, it can be delayed slightly and executed only once later.

This shows that it is not necessary to call the lower half of each interrupt; only the corresponding bit of Bh_mask and bh_active is 1 o'clock, and the lower half (do_botoom_half) must be executed. Therefore, if in the upper part (and possibly elsewhere) you decide that the corresponding half must be executed, you can specify that the lower part must be executed by setting the corresponding bit of the bh_active. Of course, if the corresponding bit of bh_active is set, it may not be necessary to execute the lower part immediately, because there must be two other conditions: first, the corresponding bit of bh_mask must also be set, in addition, is the timing of processing, if the lower part has been marked to execute, and now again marked, The kernel simply keeps the tag, and the kernel handles it when the situation permits.

If a given device has been interrupted 100 times before the kernel has a chance to run its lower half, the top half of the kernel runs 100 times and the lower half runs 1 times .

Some of the bottom-half processes in the kernel are related to specific devices, while others are more general. Table II lists the common bottom-half processes in the kernel.

Table two, the common base semi-processing process in Linux

TIMER_BH (timer)	In each periodic timer interrupt of the system, the bottom half process is marked as active and used to drive the kernel's timer queue mechanism.
CONSOLE_BH (console)	This process is used to process console messages.
TQUEUE_BH (TTY Message Queuing)	This process is used to process TTY messages.
NET_BH (Network)	For general network processing, as part of the network layer
IMMEDIATE_BH (Immediate)	This is a general process in which many device drivers use the process to queue up tasks that they want to process later.

Four. Interrupt processing whole process

The previous analysis shows that for the 0-31 interrupt vector, it is reserved for handling exception events; The 0x80 interrupt vector is used as the total entry point of the system call, while the other interrupt vectors are used to handle external device interrupts; The three processes are different.

1. The whole process of exception handling
   
   The 0-31 interrupt vector is reserved for handling exception events, the operating system provides the appropriate exception handler, and the entry of the handler is registered in the corresponding interrupt vector table entry at initialization time. When an exception occurs, the processor automatically transfers the control to the appropriate handler entry , runs the corresponding handler, and then returns to the original interrupt after the corresponding processing. Of course, as mentioned earlier, this version (2.2.5) Linux only provides a handler for the interrupt vector number 0-17.
2. The whole process of interrupt processing
   
   For interrupt vectors other than 0-31 and 0x80, it is primarily used to handle external device interrupts, and after the system has been initialized, the process of processing is as follows:
   
   When an external device needs a processing machine to interrupt the service, it interrupts the service by requiring the processor to interrupt the controller. If the CPU can handle interrupts at this time, the CPU will automatically jump to the corresponding Interrupt[i] address based on the interrupt vector number provided by the interrupt Controller and the registered address information in the Interrupt Descriptor List (IDT), and after some simple but necessary processing, the function DO_IRQ is called. The DO_IRQ function calls Do_8259a_irq and DO_8259A_IRQ, after making the necessary processing, calls the handler function in the irqaction that has been established with this IRQ for appropriate interrupt handling. Finally the processor will jump to the ret_from_intr to perform the necessary processing, and the entire interrupt processing ends back.

Outage of Linux