Re: Re: Re: [f-cpu] More Dark and Dusty Corners

[Lee Salzman <lee.salzman@lvdi.net>]

whygee wrote:
> hello,
> 
> it seems that i have let this discussion pass...
> here are some hints.
> 
> BTW, how can a user-land SW emulate a virtual OS
> if the instructions have to trap when emulation
> must be done ?
> 
   The basic idea is that all instructions you want
to virtualize must simply trap to supervisor code.
That's about it. Then for each virtualized environment
you want to keep, you maintain some tables that
essentially are what the normal processor's control
registers would store were they not virtualized.
All the instructions you then want to virtualize
are emulated by modifying/reading from this context
instead of the real registers themselves. You just
interpreter the instruction in the supervisor code,
bump the return instruction pointer past it, and
the code thinks the instruction executed in a
non-virtualized fashion.

> I have no idea of how it works on mainframes (heck)
> but here is some idea :
>  1) there is a "capability bit" which allows the running
> code to modify its own Interrupt Routine Table pointer.
> This way, the IRQ table can be stored in the user land
> and be modified at will. Software interrupts/traps
> occuring from THIS user program (of course) are redirected
> to this table. HW interrupt and failures in the setup
> of the new table are redirected to the kernel.
> Note : When the bit is set, the "local IRQ table pointer"
> is stored in the CMB. This isolates every task for each others.

   This is completely unnecessary, you only really want
one global interrupt routing table for supervisor code.
Per-thread tables are just as easily maintained via the
virtualization methods described above. Usually, when
your doing virtualization, the interrupt dispatching is
much more complex than simply dispatching to the current
thread and requires some extra maintenance by supervisor
code (and hence supervisor code needs to intercept these
interrupts anyway).

>  2) setup the table so every "supervisor" instruction is
> trapped and handled by our code. Other instructions are simply
> "forwarded" (ie : FDIV emulation...) to the kernel by re-running
> the code inside the trap handler or something like that.
> 
> you're done.

	Lee
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/