[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] More Dark and Dusty Corners
Michael Riepe a écrit :
> Again, some ambiguities crossed my way. This time it's all about
> user/supervisor mode, context switching, SRB, nested interrupts and so on.
> I hope it's not too confusing; this is rather complex stuff that isn't
> easily groked at the first glance (I'm not quite sure whether *I* grok
> everything -- and I may have overlooked some important details).
> First of all, how do we detect supervisor mode? I guess there should be
> a special register indicating the current privilege level. Bit 0 will
> be the `supervisor' bit, all other bits are reserved and must be zero
> (we can later refine the model to include specific privileges, similar
> to capabilities in the linux kernel).
Nice idea the capabilities ! It look like new protection scheme from new
But do you want to detect the mode by software or you speak from the
hardware point of view ? I don't like the idea that a software could
check in wich state it's. I imagine software like Plex86 that emulate in
parrallele many cpus. So if a soft could see a difference it could have
some problem. If there is nothing to see if a priviledged instruction is
send during a user mode a trap occur and the kernel could 'emulate' the
> When doing a context switch, the `privilege' SR should be loaded from
> the new CMB before any other operation is performed. Remember that
> the F-CPU might be interrupted in supervisor mode, and must be able to
> return to that mode when `rfe' is executed.
??? During an interrupt the cpu switch to priviledge mode and then the
kernel do what i want.
But the some trap could stay in user land to handel some error (div by
> A propos `rfe'/interrupts: something that is not clear yet is what
> happens when the F-CPU is interrupted. Is it supposed to perform
> a full context switch in all cases? That might be overkill in some
> situations, especially when the interrupt handler is short. What happens
> if the IRQ handler reaches the final `rfe' before the SRB is finished?
It freeze the code !
> According to the manual, the running SRB must finish before a new one
> can be started, but that's not appropriate -- why finish something you
> have to undo anyway?
I don't think that you're supposed to come back to the same program
after an interrupt, the kernel should choose.
Maybe we can implement such fast interrupt with shadow register (like
ARM does). Instead of saving the regiter bank, you just switch the bank
(maybe we don't need a complete new 64 registers set). But then you
could have many problems with the implementation of a preemptive system
(allowing an interrupt to interrupt an other interrupt). Because, then
you should save 2 register sets !
> Another problem is nested interrupts. When each interrupt (or exception)
> causes a context switch, we need a CMB stack -- on the second interrupt,
> the context of the first IRQ handler must be saved, and it must be
> properly restored when the "inner" handler returns. If we don't
> permit an IRQ to interrupt its own handler (that is, block it until
> the corresponding `rfe'), we may get away with one CMB per possible
> IRQ/exception, but that's already a whole lot of CMBs. Oh by the way:
> we need an `interrupt enable' SR, too.
That's the difference between instrerrupt enable and interrupt mask
(which leaves the interrupt pending until the rfe). In fact, the first
thing that the kernel should do is to prepare a new pointer to a CMB and
then renable the interrupt. In fact, it's the common problem with every
> There are several instructions which cause a user/supervisor mode
> transition and/or a context switch: `syscall'/`trap', `rfe' and `halt'.
> `rfe' is supposed to undo the effects of `syscall'/`trap' as well as
> those of an IRQ or exception; that means it needs to know *what* to
> undo if syscall, IRQs and exceptions act differently. This information
> must be saved somewhere, and must not be overwritten when a nested
> interrupt returns (that means we need an "invocation stack" here, too).
> One question is what to do when an IRQ/exception/syscall/rfe occurs.
> Always switching contexts is too expensive, IMHO. Switching only under
> certain conditions makes `rfe' a very complex task (similar to `iret'
> on Intel CPUs, which is a real nightmare). On the other hand, we have to
> save and restore certain items -- return address, privileges, interrupt
> mask, maybe the contents of other special registers -- in order to be
> able to return to the original state. And we *may* want to preload some
> special registers when entering supervisor mode in order to put the CPU
> into a defined state. But shall we really preload the general registers
> from memory when an interrupt occurs, and save them before we return to
> the interrupted task? Or discard their contents when `rfe' is executed?
> IMHO, we should leave that decision to the programmer.
> Whether or not we do a full context switch on each IRQ/exception,
> we always need a kind of "invocation stack" in order to handle nested
> interrupts properly. If we change CMBs, there must be at least one
> CMB pointer for each possible interrupt source (assuming an interrupt
> never interrupts its own handler, which may not be possible for some
> exceptions), or a stack of CMBs. If we don't, we need at least some space
> for the return address, privileges, and interrupt mask of the interrupted
> program, plus pointers to the current and last "invocation records" for
> I'd better stop now before my head starts spinning ;) But that
> doesn't mean that this topic is dead and buried now, not at all.
The only thing that we could add is that the SRB could be down in
'advance' to gain a lot of time with a shadow register bank. Imagine
that the rtc (real time clock) interrupt is control with a different
mecanism : maybe we could gain the transfert of the CMB (during the
tranfert, the cpu continue to work with the previous work). But it's
hard to find the same trick for common interrupt.
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> "All I wanna do is have a little fun before I die"
> To unsubscribe, send an e-mail to email@example.com with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/