>From ChangeLog:
- "Kevin P. Lawton" <[EMAIL PROTECTED]>:
Changed xml FAQ doc to real xml QandA type.
More cleanup of proto4.
Enough work on the prototype - time to integrate this puppy!
OK, that's as much prototyping fun as I can stand. :^) Time to
integrate the new instruction virtualization scheme into plex86
proper. Some of it needs to be filled out as it is integrated,
because I need the framework that is already built - for instance the
instruction decoder etc.
For those of you who are joining the list recently, here's a
synopsis of what's happening.
We had got plex86 booting several OSes awhile ago.
To make a virtual machine on x86, you need to
monitor the code flow, analyzing new code as it is encountered.
Mostly you have to do this to find and trap a few naughty instructions,
which can look at values you must change to virtualize the code, since
the ia32 architecture doesn't 100% naturally support virtualization.
The 1st generation of this code monitoring layer (which was called
SBE = Scan Before Execute) was relatively simplistic and made life
easier to get plex86 working. It worked by placing breakpoints
in private copies of active code pages. The offsets of instructions
had to map 1:1 to the original code page, so there was no room
to expand code inline. Breakpointing on a few naughty instructions
might not be as much of a problem, except that once you must monitor
code flow, dynamic (computed target) branches have to be monitored also.
There are a lot of these: a return(), a dense switch statement, C++ virtual
pointers, etc. That was taxing performance.
There are still a lot of things to optimize in plex86, aside from the
code monitoring component. But, I decided to improve it first, because
it is so fundamental.
The 2nd generation of code monitoring uses a quasi (very minimalist)
dynamic translation technique. Most instructions are translated
1:1, meaning they are used as-is. But code can be expanded to
inline extra code to handle naughty instructions, or call special
well cached handler functions to do the work (saves space). I put
a lot of thought into branch handling.
There are a number of factors to consider, trying to get the
best balance of performance with the least impact on memory
consumption. To make life interesting, plex86 has to manage
this dynamic translation (even though it is a simplistic form of it),
in a system-level VM environment, where process contexts are continually
scheduling in/out, and thus where the page table mappings are changing
continually.
Anyways, the 2nd generation of the code monitoring component has been
in a prototyping state for a while in the dt-testbed/proto* directories.
I'm satisfied with it now, and will begin integrating it with the main
plex86 source.
As usual, I'll take the "get it working, then get it working fast approach".
Not sure what level of initial performance we will see, but I believe the
potential is quite good. And will be complemented by accelerations such
as special guest OS specific drivers, optionally turning of user code
virtualization, and other fun stuff.
I'll keep you posted.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
