Some more plex86 thoughts.
There are a number of edge cases where we have to
handle memory accesses from guest instructions in
such a way that we can't necessarily emulate a whole instruction
at one time. An access could span multiple pages, one
which is protected because it contains guest OS structures
we need to virtualize, one which is not. Or the access
could involve non-cacheable memory such as the VGA
framebuffer in planar graphics modes. Or other memory
mapped IO. Or the instruction could try to do a
read-modify-write operation on ROM, where the read-modify
steps should still work and set flags. etc.
During the read or write phase, it may be determined
that some of the memory access must be redirected
to other parts of the virtualization. For instance,
they may be involved in a memory mapped IO range
(like the VGA framebuffer) or other non-cacheable
memory range. This area could be either handled
by an emulation component in the host user space
of plex86 or moved to the monitor space (especially
since we can handle things in a space neutral way
now).
Thus it may be necessary to switch context back to
the host to achieve this redirection, in the middle
of emulating an instruction.
It is also possible that the memory region being
accessed contains a guest OS structure we wish to
protect, and we need to act on a modification to it.
If we want to handle all these situations we have to
be prepared to emulate instructions which access memory,
not just privileged ones which naturally generate a #GP(0).
Additionally, one of the edge cases for the SBE logic
is an instruction which overlaps page boundaries or ends
on a page boundary and is not an unconditional branch.
So we may have to handle emulating all instructions.
Fortunately, since we're running x86 on x86, we can
cheat a lot. For example, for the add instruction,
if we abstract out the data access parts, we can use
the native add instruction with register operands
passing in current eflags and getting out the result
and new eflags.
We don't necessarily have to deal with all these
edge case now, but we might as well architect things
accordingly. To do this, I'm rethinking kernel/emulation.c
to be more state oriented.
Thoughts?
-Kevin
