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 [EMAIL PROTECTED]
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. -KevinThis 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?
