MMU: Lesson 2 - Programs and isolation

Program types

While dealing with programs, we have to categorize them according to the environment on which they are ran.

Initial boot loaders

 

The initial boot loader is a program, that the CPU executes once it is powered up. The CPU "knows" on which media this program is located. The CPU fetches the program from the appropriate media and executes it. This "knowledge" is beyond the scope of this lesson.

Since there is no MMU utilization at this stage, this program has access to all the available physical addresses.

Here is where the programmer should be cautious: Since the program has this full access, writing a wrong value to a location referenced by the "C" pointer, or just reading from this location, or accessing a location that is not wired to any device - will end up with either a CPU restart or just a system hung. In that event, it is better to completely power off the device and then power it on again. Of course, this program has full access to the MMU, too. How it is used is up to the software engineer that writes and maintains this program.

This engineer must have perfect understanding of the CPU and the chip's architecture, as well as knowledge of low-level languages. Many of those engineers should also have deep understanding about the initialization steps of the operating system that might be loaded  by the boot loader program. I will elaborate on the design and the operation of boot loaders in one of the upcoming posts.
Boot loader programs - in case they use the MMU to some degree - fit better into the model described in the previous page as use case 1.

Bare-metal programs

A bare-metal program can be designed in two ways:

• An extended boot loader
• A program that is loaded by the boot loader. 

In both cases - we are dealing with a program that probably has access to all the physical addresses in the system, unless some minimal setting has been done by the boot loader to limit this access.
In the bare-metal case, a program runs until

• It loads another program and directs the CPU to launch the new program, or
• It enters into a state in which it is stuck in an infinite loop, or power saving mode, waiting for some external event.

Bare-metal programs - in case they use the MMU to some degree - fit better into the model described in the previous page as use case 1.
Since there are no operating system's mechanisms in use, I'll skip the discussion about this type of program - for the time being.

Operating systems

This is what we would like to focus on.

The operating system is a program. As in the case of bare-metal programs, it is loaded by the boot loader. However, unlike bare-metal programs - it launches many other programs - that coexist in the system.

• Each one of the running programs enters into power saving mode at some point of time - and is awakened at some other point of time.
• The operating system program has full access to all the physical addresses and resources of the system. But, the programs that are ran by it - don't have this access. They have limited access, and must send requests to the operating system's program in order to extend their access rights.
• The operating system can create and execute new programs upon request from existing running programs.

Let's use the term "task" for every program, that is launched by the operating system.
Both the operating system and the tasks - in case they use the MMU to some degree - fit better into the model described in the previous page as use case 2.

Tasks

Speaking about operating systems, I believe that most of you heard the terms "process" and "thread", which are two different types of tasks. We will not discuss operating systems that don't make this distinction. For them - every program is a task.
Instead, we will put our focus on operating systems that use this distinction. 
I will try to discuss these terms with special emphasis on the relation with the MMU, because this is the main objective of the post.

The following presentation shows the steps that are taken by the operating system while establishing the relation between newly created tasks and the MMU.

Presentation 1: Establishing MMU-tasks interaction.

Let's go through the presentation.

• Slide 1: The operating system has just started up.It has created its own page table, filled it - and notified the MMU to make use of it by copying a few records from it into the some internal non-addressable CPU internal memory. The operating system is the active process.
• Slide 2: A new page table is being created. This is "Page table 1".
• Slide 3: Process 1 is being created. During the process creation, the operating system associate between the page table and the newly created process. The system fills the associated page table, and notifies the MMU that it is ready. In turn, the MMU copies a few records from it into the internal non-addressable CPU internal memory.
• Slide 4: Now the process becomes an executing component. Once the system decides to mark this process as the active one, the main function is launched (actually, this function can be called by other name). This function is the component that turns the process into a "task". The Main thread may allocated dynamic virtual memory. This means, that the page table contents are modified to allow new associations between virtual and physical memory. The MMU is notified as well. We will discuss this "activeness flag" in one of the upcoming posts.
• Slide 5: If the process is marked as active, the Main thread creates and launches other threads. Each thread is a task. Those tasks use "Page table 1"  for memory allocations.
• Slides 6-9: These steps repeat steps 2-5, but with a new page table, named "Page table 2". 

Conclusions:

• Each process is actually a program, which has its own page table.
• Each thread is a "sub-program" that uses a common page table, known to all the other threads of the process.
• Since the main function turns the process into an executing component - it must not terminate before all the other threads have done so.
• Each thread modifies the process's page table contents by issuing memory management services such as dynamic allocations or mapping. The MMU is constantly kept notified, once it happens.
• The Operating System "sees" the main function as a thread, though its roll differs from the other threads.
• This process creation scheme, is the one that provides the isolation among processes.

Stay tuned:

I hope that at this point - you all got better understanding of page tables and their relation to the MMU and the different programs that are running in the system, whether we deal with operating systems or not. 
Up to now, we have dealt with the "isolation issue". But what about "virtualization"?
Remember, physical memory is strictly limited - whether we refer to RAM or addresses assigned to devices.
Here is the hint: As demonstrated in the previous page, many PTEs are marked with an access type value of "No access". Those PTEs may not even make any association with any physical address. But - the contents of each PTE can be changed (in our case - by the operating system). In fact - it's constantly done by the operating system.

The next lesson (working on it) will deal with new components

• CPU exceptions.
• Secondary storage.   

The usage of these components is orchestrated by the operating system. We will describe how.