2
$\begingroup$

I'm reading OSTEP for my Operating Systems course, and I have a question from Chp.6.3:

Note that there are two types of register saves/restores that happen during this protocol. The first is when the timer interrupt occurs; in this case, the user registers of the running process are implicitly saved by the hardware, using the kernel stack of that process. The second is when the OS decides to switch from A to B; in this case, the kernel registers are explicitly saved by the software (i.e., the OS), but this time into memory in the process structure of the process. The latter action moves the system from running as if it just trapped into the kernel from A to as if it just trapped into the kernel from B.

I don't really understand what's going on in this following text-segment and the associated diagram:

Diagram

Specifically:

  • What is going on with the registers during the context switch? It mentions that there are "kernel registers" and "user registers"? Why are both saved, and why are each of them saved where they are? In class, I learned that the user registers are saved into the associated PCB whenever a context-switch occurs, but this seems to suggest that the user registers are saved into the k-stack and the kernel registers onto the PCB? What is the difference between these and what exactly is going on here? Details are appreciated. I really enjoy this stuff.

To be clear: to me, it seems like there is redundancy here, as from the diagram alone, it seems that user registers are being saved into PCB and k-stack and being restored from both.

$\endgroup$

1 Answer 1

5
$\begingroup$

What I think is meant by "kernel registers" in this context is any values that are stored in registers within the kernel itself.

Note: In what follows, I'm going to talk about what happens in xv6, which is the educational operating system kernel used by this book. Most modern operating systems do something broadly similar, although there are some differences.

The context (pun not intended) of what's going on here is that a user task enters the kernel somehow (e.g. a system call or an interrupt), and the kernel decides that this task should be suspended and a different task should run. The actual transfer between tasks occurs in the swtch routine. (It is not actually called switch because that is a keyword in C!)

This routine, swtch, is written entirely in assembly language because of the special job it has to do. To the caller of swtch, everything should be as if it called swtch, that routine did nothing, and it returned. But what it actually does is transfer control to a different caller of swtch.

The "user registers" that need to be saved and restored represent part of the state of the user program. But the kernel is also a program, and so some registers need to be saved by swtch in order to restore the state that the kernel was in.

The reason why they need to be saved is because of the application binary interface (ABI for short). The ABI is a standard that different operating systems define which describe how you call a function in C. It specifies things like this:

  • Which function arguments are passed in which registers or, if there are more arguments than registers, how they are laid out on the stack.
  • Some registers are designated as "caller-save", in that they should be saved by the caller before calling a function.
  • Some registers are designated as "callee-save", in that they should be saved by the called function and restored before that function returns if those registers are used by the callee.

The compiler expects callee-save registers to be preserved by the called function across a call. It might decide that the caller will use some of those registers to store local variables.

Now if you're wondering why there are some caller-save registers and some callee-save registers, it's for efficiency. In modern software, "leaf functions" can often be very small; think accessor functions in OOP, for example. They may only require one or two registers to do whatever work they need to do. The compiler knows this, and can often compile such functions using only caller-save registers, so the callee-save registers don't need to be saved.

As far as the compiler is concerned, calling swtch is like calling any other function, and so swtch needs save and restore those callee-save registers somehow. These are the "kernel registers" that the book refers to.

xv6 seems to follow the SysV ABI for Intel386. If you look at Figure 3-14 of that document, you will see three registers designated as "local register variable": ebx, esi, and edi. Along with the frame pointer ebp, these are the callee-save registers saved by swtch.

$\endgroup$
9
  • $\begingroup$ So you're saying that swtch violates the ABI, and thus "switches contexts" within the kernel? I'm a bit confused what this implies kernel-internally. I understand that user registers are saved on each k-stack, and the kernel switches k-stacks internally, thus "switching contexts", but you say the kernel is a program whose context switches too, how do you mean? Is it not purely user context? $\endgroup$ Apr 23, 2023 at 18:24
  • $\begingroup$ swtch saves callee-save registers (what the book calls "kernel registers") precisely so that it doesn't volate the ABI. $\endgroup$
    – Pseudonym
    Apr 23, 2023 at 23:58
  • $\begingroup$ The compiler is allowed to assume that, whenever it calls a function, any values stored in ebx, esi, or edi will be the same when that function returns. This also has to work for swtch, which is a normal function as far as the compiler is concerned. Therefore, swtch needs to save these registers. $\endgroup$
    – Pseudonym
    Apr 24, 2023 at 1:11
  • $\begingroup$ That's what I'm saying. The compiler assumes they stay the same, but switch swaps them for another "kernel context", so that's why it works? $\endgroup$ Apr 24, 2023 at 1:23
  • $\begingroup$ Yes, that sounds accurate. $\endgroup$
    – Pseudonym
    Apr 24, 2023 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.