Jens Nerche wrote:
>
> >Ah, life on the bleeding edge. If we could #ifdef and if ()
> >our way around this and it worked on Pentium+ and AMDs, it might
> >make a good option.
> Perhaps we shouldn't rely on things that aren't warranted? Yes,
> yes, if it's only a nice gimmick we program using such things,
> I have no problems with #ifdefs and if()s, but not the
> basic architecture. Or do we want to overthrow our architecture
> when Intel changes some undocumented features? We haven't
> the power of Microsoft... ;)
Over time, I plan for this effort to dominate the universe
so we will eventually have enough pull to dictate what
features are in future x86 CPUs. :^)
> Other things... page tables. We may want to write a pager that
> pages for our guest os. This makes the guest os pager out of
> work an we (host os and monitor) hold control over all pages.
> Or we give a set of pages to our guest (must be done while
> starting up, has anybody any idea, how to do?), then guest os
> pager works for guest tasks and guest may easily do swapping
> on hard disks. Don't know, what better, any comments?
> There was a discussion about page tables - I found in mailing
> list archiv. Were there determined some facts or is this
> a collection of ideas?
As we're going to run the guest OS kernel as-is, all the
normal guest paging code it has will be run as-is. We need to
provide the framework such that this can happen without it
realizing the pages are really mapped somewhere else.
The guest OS pager certainly won't be out of a job.
Then there is the issue of how to obtain the pages of
free memory for use by the monitor proxy the guest.
That's a good question. We talked about even using
the host's native paging mechanisms for guest pages
and redirecting page faults back to the host. As
Ulrich pointed out, there is some complexity here
that we'd be better off not dealing with until we
get things working. So that leaves working with
locked-into-memory pages. We can allocate a wad of
them up-front, or grab chunks of them as part of our
strategy, on-demand from the host. As long as
the monitor grabs a page at a time from the allocator
code, the strategy we use for the allocator can be
replaced in a very modular way, so we could use the
simple strategy of allocating the pages up-front.
Do you have a preference?
> And another question: why do you want to scan guest code?
> May be we have to do this while emulating some instructions
> to detect what guest really wants to do, but I see no need
> to scan the whole code?
Code is pre-scanned dynamically, and only the code that's about
to be executed next. None of the strategies discussed thus
far entail scanning all code.
As you can see from the discussions, pre-scanning adds some
fun to the monitor, which is why I brought up the idea of
using the SMM ideas. The fundamental reason why you need to
do pre-scanning is that you need to emulate one or more instructions
which can't be virtualized naturally by the x86 CPU. If you
can make this set have zero instructions, then you can drop
pre-scanning and all the techniques which it needs, including
all the additional memory pages which are needed. One of
the techniques requires 3 pages for each page of virtualized
guest _code_ page.
It is possible that depending on the context of the guest code
being run at a given time, that the set of instructions to
virtualize is zero. For instance, say we're normally interested
in virtualizing PUSH DS because we've skewed the RPL from 0 to 3
in the guest kernel code. When we're running guest app code,
the RPL is used as-is, so that instruction drops out of the set
(granted we're using the original value). Likely also that
the guest app code is being run with EFLAGS.IF=1. We need
this setting in the monitor so we can redirect real interrupts
back to the host. So if this were the only EFLAGS consideration,
flags related instructions may drop out of the set also, like PUSHF.
While running guest kernel code, the guest may try to clear IF.
We can't let it really do this, so we either have to virtualize
things or use the native virtual interrupt facilities.
Now you get an idea why I wanted to look into the SMM and PVI
stuff before diving in.
-Kevin
