Ring 0 multithreading

[protegee6155]

Well, never mind — I think I should research this topic a bit more so I don’t end up asking overly general questions for nothing. After learning more, I’ll probably create a new post with a more meaningful and focused question.

In any case, thank you all for the help!!!

[bellezzasolo]

Hmm, okay, that somewhat makes sense.
So in that case, should my interrupt-handling code—the part that executes iret at the end—also serve as my context-switch function?

It's an interesting one to tackle design-wise. You almost certainly want the ability to context-switch in a device interrupt - for the purpose of timer preemption. And context-switching in a syscall is key to blocking.

Thing is, you also want to send the EOI in the device interrupt case. So you need to make sure the EOI is sent before doing the context switch.

Since you also want to restore flags, at the point of switching, IRET isn't actually a bad way of doing it. With a bit of pseudo-assembly:

Code: Select all

context_switch(current_context, next_context):
pop rax ;return address
;Build iret frame
pushfq
push cs
push rax
mov [current_context.stack_ptr], rsp

mov rsp, [next_context.stack_ptr]
iretq

[Octocontrabass]

So in that case, should my interrupt-handling code—the part that executes iret at the end—also serve as my context-switch function?

No. That makes context switching more complicated for no reason, and that extra complexity will come back and bite you later. Stick to something like the switch_to_task example.

Since you also want to restore flags,

Do you? Tasks that will return to ring 3 will restore their flags when they return to ring 3. What other flags would you want to restore?

[bellezzasolo]

So in that case, should my interrupt-handling code—the part that executes iret at the end—also serve as my context-switch function?

No. That makes context switching more complicated for no reason, and that extra complexity will come back and bite you later. Stick to something like the switch_to_task example.

Since you also want to restore flags,

Do you? Tasks that will return to ring 3 will restore their flags when they return to ring 3. What other flags would you want to restore?

The interrupt flag. While you might get away with mov rsp, [x] being atomic, you're still in a context switch procedure, quite possibly triggered from a hardware interrupt. To avoid stack overflow, you've probably done something like:

Code: Select all

cli
EOI()
next_context = schedule()
if(next_context) context_switch(next_context)
iret

As if you have interrupts enabled, it's theoretically possible to get into an overloaded state where another int keeps firing before you iret.

And just generally being interrupted during a context switch seems messy to reason about as you now hav reentrancy into the scheduler.

But, if you go into it with IF off, you now resume on a syscall / sysret, which doesn't necessariy touch flags (and you may well want the kernel to be preemptible while servicing a system call).

Neater I think to just save/restore flags as part of the context switch.

[nullplan]

And just generally being interrupted during a context switch seems messy to reason about as you now hav reentrancy into the scheduler.

So long as stack overflow is avoided (and if you are implementing a pre-emptible kernel, you typically still don't re-enable the interrupt flag if only a small amount of stack remains), it is not harder to reason about an interrupt in the scheduler than an interrupt in any other place. All shared state must be spinlock-protected anyway (unless you have the kind of space brain necessary to implement lockless algorithms) and spinlocks shared with interrupt handlers must disable the interrupt flag when taken.

Neater I think to just save/restore flags as part of the context switch.

Yes, if the interrupt flag can be different between contexts, then it should also be preserved by the task switcher. That is one more pushfd before and one more popfd after the stack switch.

Indeed I left a lot out of there. For example, switching CR3, possibly handling the debug registers, the FPU/SSE and other state. But all of this can be added later, once the principle is out of the way.