x86处理器如何“知道”正在运行的多个进程？

Question

I'm sure the answer to this question is somewhere on the internet (or even stackoverflow), however, I'm having a difficult time formulating the question to get good results.

I've been studying x86 for the last week and have been confused by the concept of x86 processors being 'aware' of different processes running. For example, when operating in protected mode, the x86 processor is able to limit the memory in which a process can access. This makes me believe the processor is somehow aware of multiple processes existing.

This confuses me. From the processor perspective, I would assume that it is just getting a list of instructions to execute and it is the responsibility of the operating system to order those instructions (via time slices, memory management, etc.) such that multiple processes can run. From the processors perspective, I assume all it would see is a sequential list of instructions.

However, due to the fact that an x86 processor can limit memory access by process, the CPU is somehow aware that there are multiple processes.

Answer 1

The CPU is not aware of process scheduling, the latter can be implemented in many different ways while the former must be a general purpose chip.

What happens is this

1. The OS is in control (read: the CPU is executing an OS routine) and setups a sandbox A to be used to run a quantum of Process A.
2. Process A is executed inside this sandbox.
3. A periodic interrupt occurs, the routine that serves this interrupt belongs to the OS and it is outside the sandbox.
4. The OS is in control and setups a sandbox B to be used to run a quantum of Process B.
5. Process B is executed inside this sandbox.

The process repeats.

The protected mode let the OS create sandboxes, particularly it defines privileges (in Real mode every program has the same privileges) so that Process A and Process B cannot escape the sandbox (for example by disabling the interrupts and running forever).

The CPU is not aware of what it's happening, it just see a sequence of instructions executed under different privileges and "constraints".
It is the OS that configures the CPU differently before executing a different program.
This also helps to explain the difference between threads and processes: threads scheduling doesn't change the sandbox.

As Jester remembered me in the comments, x86 has support for task management.
However, an HW task doesn't map one-to-one to an OS process (IIRC this feature is scarcely used by the major OSes).

Reading Intel Manual 3 will help you understand what the CPU is capable of and where the responsibility for a secure OS shifts from the CPU to the kernel.

Answer 2

The CPU sees ONE process at a time. The CPU has no knowledge of a process unless it is executing.

For example, when operating in protected mode, the x86 processor is able to limit the memory in which a process can access.

What you are describing is logical address translation. The Operating system defines a set of page tables for a process that provide the mapping from a logical page to physical page frames. The page tables also define the access allowed to those pages. Each process has its own set of page tables (in some cases the parts of the set may be shared).

The structure of the page tables is defined by the processor. The contents of those tables are established by the operating system. Thus, the "limit" on the memory is comes from the operating system.

Part of the procedure for changing the current process (triggered by the operating system) is to swap the page tables for the new process in place of the ones for the old.

The processors sees those "limits" on memory access from the perspective of the currently executing process and at any given time has no knowledge whatsoever of the equivalent "limits" (page tables) of any other process.

However, due to the fact that an x86 processor can limit memory access by process, the CPU is somehow aware that there are multiple processes.

The CPU is only aware of the page tables of the current process. It only knows the "limits" on the process that is executing. The current page table set defines what physical memory the process can access and how it may access it (read/write/execute + restrictions by mode).

From the processors perspective, I assume all it would see is a sequential list of instructions.

Plus interrupts that are a key part of process scheduling.

Answer 3

From the hardware's perspective, you are right that all a CPU does is "execute instructions", one at a time. In some (perhaps mildly simplified) sense, that's all that's going on.

If you had some specific computational task to perform, you could indeed write a suitable stream of instructions so that you can power on your hardware, it executes your instructions, and then halts, or shuts down, or whatever. That's how very early computers were in fact operated.

However, this mode of operating a computer is extremely unwieldy and doesn't scale at all, since it requires a single operator to take responsibility of everything , and in the process reinventing all sorts of wheels. That's where the concept of an operating system comes in: The OS is a specific kind of instruction stream that's loaded at start-up which can in turn load up and execute other bits of instructions, dynamically . This compartmentalization allows for reuse of core functionality (think device drivers), and to adapt the functionality of the machine dynamically (ie while it's running, as opposed to reprogramming and resetting it). Morever, it allows those parts of the instructions that are loaded dynamically to be authored by different people, so that we have a single platform that can execute "user-defined instructions", ie what we conventionally understand as a "program".

So now we have all the pieces: The code that the CPU executes when it is powered up is the operating system, and the operating system dynamically manages the execution of further code. Most of these units of execution are called processes . (But not all code is like this. For example, loadable kernel modules in Linux are dynamically loaded, but don't constitute a process.) That is, a process is an abstract concept in the operating system that delineates between the OS's own code and the "hosted" code that it runs on request.

Depending on the type of OS, execution of processes may have fancy features such as virtual memory (each process sees its own, separate memory) and protection (no process can interfere with the operation of the OS or of other processes). OSes implement such features by using CPU features: a memory manager unit that provides address translation, and protection rings that limit the instructions available to a piece of execution. Not all OSes do this, though; in DOS, for instance, every process has full access to the physical memory and thus to the OS's state. Regardless, an OS typically provides an API for processes (eg "system calls"), again using hardware features (interrupts or special system call instructions), and user code generally interacts with the environment through this API rather than talking to peripherals directly. For example, this means that hardware drivers are only implemented by the OS, and user code can make opaque "print output" calls without having to know the details of the available output devices.

Example: Maybe it's useful to illustrate what processes are on the popular Linux operating system, running on x86 hardware: A new process is started when an existing process (eg a shell, or init ) calls the clone system call, by raising interrupt 128. The interrupt makes the CPU transfer control to the interrupt handler routine, which was set up by the OS during boot-up. When the interrupt handler is entered, the CPU switches to ring 0, privileged mode. The interrupt handler makes the kernel create the new process, and then transfers control back to the calling process (which implies switching to protection ring 3, unprivileged; processes only ever execute in ring 3). For the creation of the new process, the kernel creates the relevant internal book keeping structures, sets up new page tables in the MMU, and then transfers control to the entry point for the clone call, similar to the way the original call returns. (I'm glossing over issues of scheduling here; only one transfer of control happens at a time, and the others are "scheduled" to happen later.) The fact that a new process exists now is merely reflected in the kernel's internal bookkeeping data. The CPU doesn't know anything about it; all it sees is that interrupts get fired and page tables get changed regularly.