how does instruction execution work?

[Samuel Rydh]

On Fri, Feb 13, 2004 at 09:52:45PM +1100, James Whitwell wrote:
> Hi,
> 
> Can anyone give me a clue on how instruction execution works?  I've 
> been starting at src/cpu/ppc/mainloop_asm.S, but I'm not at all clear 
> on what's going on.  Is it something to do with MOL_KERNEL_ENTRY_MAGIC 
> being an illegal instruction?

It basically works like this:

Userspace saves a few registers on the stack
(in mainloop_asm.S) and then issues an illegal instruction.
This illegal instruction is trapped by the MOL kernel module.

The MOL kernel module saves the MMU context, sets up
a CPU few registers (e.g. the MMU context for MacOS) and
enters mac-mode. The CPU starts processing MacOS code directly.

Control is returned to the kernel module (not mainloop_asm.S)
when an exception occurs. The exception is typically
caused by one of the following events:

- Mac OS tries to execute a privileged instruction
- A page fault occurs (it might be a "real" page fault
that requires a mac side exception or it might access of 
a MOL RAM page that happens to be in the linux swap).
- A DEC exception occurs (end of time slice or a mac-DEC
exception)
- An IRQ occurs (MOL restores the normal MMU context
and invokes the standard exception handler; MOL does not
care about hardware so the IRQ exception is never meant
for MOL).

Usually, the kernel module handles the exception completely
and returns to virtualization mode.

Control is passed back to MOL-userspace (mainloop_asm.S) whenever
something needs to be done from userspace. Disk access,
I/O emulation, timer overflows and similar things are
all handled from userspace. Userspace also provides
some support for the CPU virtualization itself although most
things are handled entirely by kernel module. The switch
to usermode is semi-expensive so the boundary crossing
must be avoided whenever possible.

Userspace also regains control after C-level kernel module
code has been invoked (it is difficult to return directly to
the virtualization mode since one would have to teach the
kernel to hop through loops). The return point is
more or less the illegal instruction that will
trigger the switch back to virtualization mode.

Hope this helps a bit... The mainloop_asm.S code
basically does the following:

	for( ;; ) {
		int do_this = enter_virtualization_mode();

		/* why did we return to userspace this time? */
		switch( do_this ) {
		case DO_IO:
			do_the_io();
			break;

		case DO_SOMETHING_ELSE:
			...
			break;

		case DO_NOTHING:
			/* some technicality required a return to userspace */
			break;
		}
	}

It just becomes a bit more complicated due to the usage
of assembly...

/Samuel