[EMAIL PROTECTED] (Ramon van Handel) wrote:
> To the point. I think that during the initial stages of development (i.e.,
> until we have a stable base for further development), we should work with a
> TODO list. This list should contain all of the things that need to be
> implemented still in the near future (in order of urgency), and who is
> working on which one. This should make development a lot easier as there
> can never be
> confusion about who's working on what, or what needs to be done. The way it is
> now, it is hard for me (and probably for others as well) to see what needs
> doing, so if I find myself having some free time I don't know how I can
> make myself useful :).
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 ...
- Do all the things I forgot to mention ;-)
> I suggest that somebody (preferably Kevin) makes this list and that it always
> gets actively updated (put it in CVS -- PS Kevin, when are we getting that ?)
Well, I haven't heard from the FastXS people yet. I'll try to contact
them again and find out when CVS will be up. As soon as it's working
I'll put the existing versions in and post some info as to how to
access and use the CVS tree ...
Bye,
Ulrich
