To control the execution of process, the kernel must be able to suspend the execution of the process
running on the CPU and resume the execution of some other process previously suspended. This
activity goes variously by the names process switch, task_switch, or context switch.
Hardware Context
While each process can have its own address space, all processes have to share the CPU registers. So
before resuming the execution of a process, the kernel must ensure that each such register is loaded
with the value it has when the process is suspended.
The set of data that must be loaded into the registers before the process resumes its execution on the
CPU is called the hardware context. The hardware context is a subset of the process execution context,
which includes all infomation needed for the process execution. In Linux, a part of the hardware context
of a process is stored in the process descriptor, which the remaining part is saved in the Kernel Mode
Stack.
In the descriptor that follows, we will assume the prev local variable refers to the process descriptor of
the process being switched out and next refers to the one being switched in to replace it. We can thus
define a process switch as the activity consisting of saving the hardware context of prev and replacing
it with the hardware context of next. Because process switches occur quite often, it is important to
minimize the time spent in svaing and loading hardware contexts.
Old version of Linux took advantage of the hardware support offered by the 80x86 architecture and
performed a process switch through a far jmp instruction to the selector of the Task State Segment
Descriptor of the next process. While executing the instruction, the CPU performs a hardware context
switch by automatically saving old hardware context and loading a new one. But Linux 2.6 uses software
to perform a process witch for the following reasons:
Step-by-step switching performed through a sequence of mov instruction allows better control over
the validity of the data being loaded. In particular, it is possible to check the values of the ds and ss
segmentation registers, which might have been forged by a malicious user. This type of checking is not
possible when using a single far jmp instruction.
The amount of time required by the old approach and the new approach is about the same. However,
it is not possible to optimize a hardware context switch, while there might be room for improving the
current switching code.
Process swithing occurs only in Kernel Mode. The contents of all registers used by a process in User Mode
have already been saved on the Kernel Mode Stack before performing process switch. This includes the
contents of the ss and esp pair that specifies the User Mode stack pointer address.
Task State Segment
The 80x86 architecture includes a specific segment type called the Task State Segment (TSS), to store
hardware contexts. Although Linux doesn't use hardware context switches, it is nonetheless forced to set
up a TSS for each distinct CPU in the system. This is done for two reaons:
When an 80x86 CPU switches from User Mode to Kernel Mode, it fetches the address of the Kernel Mode
stack from the TSS.
When a User Mode process attempts to access an I/O port by means of an in or out instruction, the CPU
may need to access an I/O Permission Bitmap stored in the TSS to verify whether the process is allowed
to address the port.
More precisely, when a process executes an in or out I/O instruction in User Mode, the control unit performs
the following operations:
It checks the 2-bit IOPL field in the eflags register. If it is set to 3, the control unit executes the I/O instruction.
Otherwise, it performs the next check.
It accesses the tr register to determine the current TSS, and thus the proper I/O Permission Bitmap.
It checks the bit of the I/O Permission Bitmap corresponding to the I/O port specified in the I/O instruction. If
it is cleared, the instruction is executed; otherwise, the control unit raises a "General Protection" exception.
The tss_struct structure describes the format of the TSS. As already mentioned in Chapter 2, the init_tss
array stores one TSS for each CPU on the system. At each process switch, the kernel updates some fields of
the TSS so that the corresponding CPU's control unit may safely retrieve the information it needs. Thus, the
TSS reflects the privilege of the current porcess on the CPU, but there is no need to maintain TSSs for processes
when they are not running.
Each TSS has its own 8-byte Task State Segment Descriptor (TSSD). This descriptor includes a 32-bit base field
that points to the TSS starting address and a 20-bit Limit field. The S flag of a TSSD is cleared to denote the fact
that the corresponding TSS is a Sytem Segment.
The type field is set to either 9 or 11 to denote that the segment is actually a TSS. In the Intel's original design,
each process in the system should refer to its own TSS; the second least significant bit of the Type field is called
the Busy bit; it is set to 1 if the process is being executed by a CPU, and to 0 otherwise. In Linux design, there is
just one TSS for each CPU, so the Busy bit is always set to 1.
The TSSDs creatd by Linux are stored in the Global Descriptor Table (GDT), whose base address is stored in the
gdtr register of each CPU. The tr register of each CPU contains the TSSD Selector of the corresponding TSS. The
register also includes two hidden, nonprogrammable field; the Base and Limit fields of the TSSD. In this way, the
processor can address the TSS directly without having to retrieve the TSS address from the GDT.
The thread field
At every process switch, the hardware context of the process being replaced must be saved somewhere. It cannot
be saved on the TSS, as in the original Intel design, because Linux uses a single TSS for each processor, instead of
one for every process. Thus, each process descriptor includes a field called thead of type thread_struct, in which
the kernel saves the hardware context whenever the process is being switched out. As we will see later, this data
structure includes fields for most of the CPU registers, except the general-purpose register such as eax, ebx, etc.,
which are stored in the Kernel Mode Stack.