Jens Nerche wrote:
>
> Hiho!
> There's a lot discussion about what to do in FreeMWare-Project.
> But what are the next steps? I think, there are some possibilities:
> take a kernel (the linux kernel?) run it in vm, look where it crashes
> and change the crash reason - or:
> take a minimal test kernel and develop it by installing more and more
> os features. I think we have to learn a lot about virualization itself,
> so I favorite the second.
> Most brain torturing thing may be to tinker the adress spaces in a
> clever way. There are some articles in the mailing list archive about
> that. To test the one or another, we should add the abstraction of
> address spaces first to the test kernel. Once we have address spaces,
> may be a little effort to add activities (call it threads, tasks,
> processess...).
Ramon wrote a very slim kernel call nullkernel for just this purpose.
The idea is for it to use very few features so we would not have
to virtualize much to start with. It's available by FTP. It doesn't
even use paging. There are 2 variants. One doesn't use interrupts
for scheduling (thus doesn't even need IO to program the PITs).
An excellent first kernel to work with. We can add features to it as
we go.
> What basic techniques are needed? Catching exceptions, traps and
> interrupts: detect, if it is for vm and redirect them. Emulation
> of privileged instructions. Other?
For nullkernel, the things we need to look for are:
- user code uses system call (soft interrupt)
- system code uses transitions to user code
- writes go to VGA text framebuffer memory (0xB8000) for some
output to screen.
- LTR, IRET, MOV CS,xyz, LIDT, PUSHFL/POPFL, LGDT instructions
- control transfers
If you use the interrupt based slant, then you have to add more
framework, such as the mechanisms for tying IO device emulation
into FreeMWare, and timing of execution using the Time Stamp Counter
with RDTSC and WRTSC instructions (available Pentium+).
Also, we need to be able to load the kernel image right into VM
memory and run it without intervention of any of the BIOS. This
is so we can start with virtualizing 32bit-only code. We have
proved this works with nullkernel, as with a small hack in bochs,
it runs nullkernel with no BIOS intervention. In order for it
to be able to spew to the text VGA screen, we had to make sure
the VGA registers where init'd. Since the VGA BIOS does this,
I took a snapshot of all the read/writes that occurred upon
BIOS startup and sent them to a file. This way we can
just read them back to the VGA emulation with no BIOS.
For starters, we could just write text to stderr rather
than redirect to emulation though.
> I played a little bit with FreeMWare and missed some things. Will
> change them next time:
> * configuration details (defines, ...) in a config.h (yes, I know
> top-level-config.h - has somebody a better idea?)
> * parsing command lines in "user"
> * reading and parsing of a config file
> * give some configuration data to test kernel (for example,
> address space layout of test kernel should be configurable to play
> with it)
You are hereby person in charge of these issues. :^)
I've got to finish up a final commitment which is tying me up
time-wise, but will be done with that soon. But here's some
virtualization related thoughts...
The RPL field of the selector; is there a way to make this
field show the value which the guest expects, say RPL=0, yet
have the descriptor access rights be PL=3? This way
instructions which push segment registers would see the
correct RPL, but the actual privilege level would trap
on system instructions. Look though articles on the
descriptor cache and system management mode.
Some related articles at:
http://www.rcollins.org/ddj/ddj.html
Look into CR4.PVI, Protected mode Virtual Interrupts. This
may come in handy. There's a paper on it, on rcollins.org
or x86.org. If I remember right, there's a few gaps that need
to be filled in. Also, look at VME, which is the virtual mode analog
to PVI.
http://www.rcollins.org/articles/articles.html
When I complete doing what I'm working on now I plan to look
into this stuff, and writing some test code to check it out.
It would be cool to find out we don't need to pre-scan
instructions at all, given we could squeeze enough juice
out of SMM and PVI tricks.
Also, WRT control transitions, like jumps, calls etc. When
necessary to virtualize them, whenever possible, I'd like
to use some kind of stubs or other patch to make use of
native x86 control transfers to effect the transfer.
Essentially, I'm thinking in terms of "emulating" as few
of the features as possible and making use of the native
CPU features as much as possible. Kinda obvious, but hey...
-Kevin
