Ulrich Weigand wrote:
> Well, a simple TODO list could be useful, of course. Off the top of my
> head there's a few tasks that come immediately to mind:
>
> - Start implementing proper exception handlers in the monitor; exceptions
> must either be forwarded to the guest, handled by the monitor, or else
> abort the VM. Most interesting are of course the page fault and GPF
> handlers ;-)
>
> - Add a instruction analyzer/decoder to be used e.g. inside the GPF
> handler to find out which instruction caused the fault. (I have an
> decoder already written for another project, this might be useful ...)
>
> - Start virtualizing certain system instructions. We'll probably start
> with those that are used by the nullkernel; most important seem to be
> LDT/GDT/IDT accesses. This will require to set up a framework to
> move the real monitor tables to the linear address expected by the
> guest, protected by page access privileges, and maintain the 'shadow'
> tables at some other location ...
>
> - One prerequisite to the above will probably be to add some memory
> management faciliy for use inside the monitor; this should probably
> hand out memory one page at a time from a pool, and if this pool
> runs empty, drop to the host and request another batch of pages.
>
> - Start thinking about the framework for hardware emulation; this
> could be done in parallel by running a purely ring-3 guest which
> doesn't need much virtualization support, but could be used to
> test hardware accesses ...
Yes, this is a great initial TODO list. These things do have
a lot of intersect though. Over time, items on the list will
be more modular, and easier to be done separately.
That's an interesting point about running a pure ring3 guest.
That wouldn't require the virtualization of protection level
transitions etc. Could start by virtualizing one thing
at a time. True, we could virtualize IO in ring3 code as
well. It would be a bogus OS anyways, so might as well.
Good stuff.
More later, gotta run...
-Kevin
