Hello:
I thought that some of you might be interested in this. If this message
should not have been posted to this list please let me know.
Darren Wiebe
dkwi...@hagenhomes.com
--- Begin Message ---
Hey folks,
It's been awhile. Sorry, I've been busy working on other
fronts, but I did have time to put together a first go
at the virtualization framework we need for FreeMWare.
ftp://ftp.freemware.org/pub/freemware/fmw-990817b.tar.gz
Which if you're having problems, is really just:
ftp://bochs.com/pub/freemware/fmw-990817b.tar.gz
Attached is the "fmw-990817b.README" that goes along with it.
-Kevin
This is the beginnings to the virtualization framework that we
need for FreeMWare. I have compiled it and run it on:
Linux 2.0.36 (came with Red Hat 5.2)
Linux 2.2.5-15 (came with Red Hat 6.0)
I've made an attempt to keep things modularized in
respect to the host OS. Anything OS specific should
be put in "kernel/host-xyz.c" or "include/host-xyz.h".
This code is extremely experimental, and will likely
result in a system crash, and who knows what other
ill effects. Don't run it on a system with any
important data on it, and make liberal user of
the sync command! Expect to have to use the power
button.
We have to clean up the ioctl interface, using
macros instead of passing raw numbers I pulled out
of a hat, etc, etc. This was my first Linux kernel
driver, so don't assume I did anything correctly. :^)
-Kevin
Directions for install etc.
---------------------------
Go into the user directory and type make.
user> cd user
user> make
Go into the kernel directory and type make.
user> cd ../kernel
user> make
Make the device node for freemware, as root user:
root> mknod /dev/freemware0 c 63 0
Fire up the kernel module:
root> insmod fmw.o
As a regular user, fire up the user program:
user> cd ../kernel
user> ./user # defaults to 1 iteration
-or
user> ./user 10 # any number of iterations here
Whenever you recompile the kernel stuff, or want to
get rid of the kernel module, remove the old
kernel module first. As root:
root> rmmod fmw
Each time the host switches to the monitor/guest
environment and runs that context. Normally, execution
will continue in that context until a hardware interrupt
occurs or other exception. The monitor interrupt handler
switches back to the host context to handle the interrupt.
The monitor/guest context will not resume execution until
the next ioctl() call from the user program.
NOTE:
By default, I have a macro called TEST_MODE set to 1,
in kernel/monitor.c. In this mode, rather than waiting until
an interrupt hits, control will be passed immediately back
to the the host. This is to test that the switching back/forth
between host/monitor+guest works, without interrupts.
I have not yet got interrupts redirection working properly.
If you set TEST_MODE to 0 and recompile, an interrupt seems to
cause everything to switch back to the host context, but
then the system hangs after a short period of time,
or causes a kernel oops. I have not tracked this down
yet. It does register in /proc/freemware, that a redirection
of an IRQ0 occurred. Something is getting screwed up with
interrupts in the kernel perhaps, after the software interrupt
call to invoke the host kernel interrupt handler for the
hardware interrupt we received while in guest context.
Any ideas on what the problem is?
--- End Message ---
