I am currently reading Operating Systems - Three Easy Pieces, by Remzi and Andrea, and at the part on context switching, it states that during an interrupt, the registers of the running process is saved onto its kernel stack, and then the registers for the next process is loaded from its PCB, but then later on it says its loaded from its kernel stack
My question is, why load the registers from the PCB when you later load them from the kernel stack, and what even is the point of a PCB when you save all the info on the kernel stack?
I have created a diagram to help understand the flow better. I've organized it similar to the figure in the question.
During a context switch, does the OS use PCB or kernel stack to restore registers?
It uses both.
why load the registers from the PCB when you later load them from the kernel stack
Because you only load the esp of the Kernel Stack from the PCB, and the rest of the registers from the Kernel Stack.
what even is the point of a PCB when you save all the info on the kernel stack
Because you DON'T save ALL the info on the Kernel Stack, you save MOST info on the Kernel Stack. The very location of the Kernel Stack (aka its esp) is stored in the PCB.
NOTE: Kindly note that the diagram is purely for illustrative purposes (i.e. to specifically and only answer the OP's question as to what is the point of separately saving the user-space registers and kernel-space registers into the Kernel Stack and PCB respectively). It is not entirely accurate in the sense that there are a bunch of other registers that get saved & restored depending on the OS and its architecture. Nevertheless, it illustrates the answer to the OP's question accurately.
Related
I was given this exact question on a quiz.
Question
Answer
Does the question make any sense? My understanding is that the OS schedules a process and manages what instructions it needs the processor to execute next. This is because the OS is liable to pull all sorts of memory management tricks, especially in main memory where fragmentation is a way of life. I remember that there is supposed to be a special register on the processor called the program counter. In light of the scheduler and memory management done by the OS I have trouble figuring out the purpose of this register unless it is just for the OS. Is the concept of the Stored Program Computer really relevant to how a modern computer operates?
Hardware fetches machine code from main memory, at the address in the program counter (which increments on its own as instructions execute, or is modified by executing a jump or call instruction).
Software has to load the code into RAM (main memory) and start the process with its program counter pointing into that memory.
And yes, if the OS wants to page that memory out to disk (or lazily load it in the first place), hardware will trigger a page fault when the CPU tries to fetch code from an unmapped page.
But no, the OS does not feed instructions to the CPU one at a time.
(Unless you're debugging a program by putting the CPU into "single step" mode when returning to user-space for that process, so it traps after executing one instruction. Like x86's trap flag, for example. Some ISAs only have software breakpoints, not HW support for single stepping.)
But anyway, the OS itself is made up of machine code that runs on the CPU. CPU hardware knows how to fetch and execute instructions from memory. An OS is just a fancy program that can load and manage other programs. (Remember, in a von Neumann architecture, code is data.)
Even the OS has to depend on the processing architecture. Memory today often is virtualized. That means the memory location seen by the program is not the real physical location, but is indirected by one or more tables describing the actual location and some attributes (e.g. read/write/execute allowed or not) for memory accesses. If the accessed virtual memory has not been loaded into main memory (these tables say so), an exception is generated, and the address of an exception handler is loaded into the program counter. This exception handler is by the OS and resides in main memory. So the program counter is quite relevant with today's computers, but the next instruction can be changed by exceptions (exceptions are also called for thread or process switching in preemptive multitasking systems) on the fly.
Does the question make any sense?
Yes. It makes sense to me. It is a bit imprecise, but the meanings of each of the alternatives are sufficiently distinct to be able to say that D) is the best answer.
(In theory, you could create a von Neumann computer which was able to execute instructions out of secondary storage, registers or even the internet ... but it would be highly impractical for various reasons.)
My understanding is that the OS schedules a process and manages what instructions it needs the processor to execute next. This is because the OS is liable to pull all sorts of memory management tricks, especially in main memory where fragmentation is a way of life.
Fragmentation of main memory is not actually relevant. A modern machine uses special hardware (and page tables) to deal with that. From the perspective of executing code (application or kernel) this is all hidden. The code uses virtual addresses, and the hardware maps them to physical addresses. (This is even true when dealing with page faults, though special care will be taken to ensure that the code and page table entries for the page fault handler are in RAM pages that are never swapped out.)
I remember that there is supposed to be a special register on the processor called the program counter. In light of the scheduler and memory management done by the OS I have trouble figuring out the purpose of this register unless it is just for the OS.
The PC is fundamental. It contains the virtual memory address of the next instruction that the CPU is to execute. For application code AND for OS kernel code. When you switch between the application and kernel code, the value in the PC is updated as part of the context switch.
Is the concept of the Stored Program Computer really relevant to how a modern computer operates?
Yes. Unless you are working on a special custom machine where (say) the program has been transformed into custom silicon.
I am reading Chap9 of Operating System Concepts and the concept of pure demand paging is described as follows:
In the extreme case, we can start executing a process with no pages in
memory. When the operating system sets the instruction pointer to the first instruction of the process, which is on a non-memory-resident page, the process
immediately faults for the page....
But if NONE of the pages, particularly the pages containing code, are in memory, how does the OS know where the program counter is in the first place? Is program counter set as part of process creation by inspecting the program image on disk? If so, I would assume the OS knows the format of the binary image and can directly access that info on disk. And it will only make sense if somehow this info is stored in the part of the program image not needed during program execution, if OS decides not to bring the page containing this info into memory.
To summarize, I would like to know:
How is program counter set for a new process if using pure demand paging?
Is any real OS using pure demand paging and what benefit does it have?
How does an executable's binary format (e.g. ELF, PE formats) help the OS do demand paging (OS needs to know where the first page is at least?)
In the Sparc V8 architecture we have some N register windows. Generally an RTOS during context switching pushes and pops registers. Is it possible( or already has been done) to use each of these register windows as one of the thread. This will make switching onto next thread as good as shifting register window and pushing and popping PSR ! Thus saving context switching time and enabling faster context switching frequency.
Maybe, it depends on what you mean by threads and how many.
The register windows are built around the idea of function calls and returns, implementing this in hardware and software traps with well defined operation. If your threads are just functions that get called in a round robin fashion etc... then yes they will get switched in this manner as will any other functions called from your "thread". That said once your have more functions than the number of register windows they will start getting paged in and out of the register file.
From the perspective of OS and User code... you don't have control of what happens when you enter and leave a register window as that is implemented as a trap as I understand it probably in the firmware. If you go changing how that works you aren't running a Sparc anymore because what it does there is defined in the Spec.
The whole point of Register windows has always been fast context switching.. but other aspects of Sparc hardware such as the TLB can get in the way of that... in the context of a Sparc MCU with a flat address space... then yeah it would be really fast.
I need to implement a multitasking system with MPU for ARM Cortex M3/M4 processors.
In that system, there will be a Kernel which manages resource in Privileged mode and user applications in Unprivilege mode. And I want to seperate User Application from rest of it and system resources.
Therefore, when I switch to a new task, I am releasing Stack and Global Memory area of user application.
It can be done easily using ARM Cortex MPU registers.
But problem is that, when a context switching is occurred, I need to use also some global variables of Kernel.
For example, I am calling a function to get next TCB in PendSV Handler during context switching but task pool is out of user app area and it is protected from user application.
So, it seems there should be balance, right? What are the secure and efficient strategies for memory protection?
Privilieged mode can be raised before context switching when Yield function is called but it does not seem a good solution.
What are the general strategies on that issue?
Perhaps you might take a look at an existing open source implementation and see what design decisions were made there. FreeRTOS for example has Cortex-M MPU support here; it may not answer your exact question directly and you may have to inspect the source code to get complete details.
Possibly divide the data memory into three regions - user, kernel and shared.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.