Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Aug 1999 15:39:14 -0600
From:      Darren WIebe <dkwiebe@hagenhomes.com>
To:        freebsd-hackers@freebsd.org
Subject:   [Fwd: First FreeMWare release!]
Message-ID:  <37B9D682.2C9D9979@hagenhomes.com>

next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------9A8E440C3DAFAA4FB2310FCB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
dkwiebe@hagenhomes.com
--------------9A8E440C3DAFAA4FB2310FCB
Content-Type: message/rfc822;
 name="nsmail37B9D67A06302F0"
Content-Disposition: inline;
 filename="nsmail37B9D67A06302F0"

Return-Path: owner-freemware@fastxs.net
Received: from localhost (localhost.hagens.ab.ca [127.0.0.1])
	by freebsd.hagens.ab.ca (8.9.2/8.9.2) with ESMTP id MAA03019
	for <dkwiebe@localhost>; Tue, 17 Aug 1999 12:42:24 -0600 (MDT)
	(envelope-from owner-freemware@fastxs.net)
Received: from jasper.heartland.ab.ca
	by localhost with IMAP (fetchmail-4.7.0)
	for dkwiebe@localhost (single-drop); Tue, 17 Aug 1999 18:42:25 +0000 (UTC)
Received: from safeco2.safeco.net (safeco2.safeco.net [216.71.84.27])
	by jasper.heartland.ab.ca (8.9.0/8.8.5) with ESMTP id NAA12248
	for <dkwiebe@heartland.ab.ca>; Tue, 17 Aug 1999 13:00:53 -0600 (MDT)
Received: from lightning.fastxs.net (ns1.fastxs.net [212.204.201.31])
	by safeco2.safeco.net (8.8.5/8.8.5) with ESMTP id OAA06273
	for <dkwiebe@hagenhomes.com>; Tue, 17 Aug 1999 14:07:17 -0500
Delivered-To: freemware-list@fastxs.net
Received: by lightning.fastxs.net (Postfix, from userid 0)
	id 59E23E8009; Tue, 17 Aug 1999 21:08:28 +0200 (CEST)
Delivered-To: maillist@fastxs.net
Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2])
	by lightning.fastxs.net (Postfix) with ESMTP for <freemware@fastxs.net>
	id 050C9E8009; Tue, 17 Aug 1999 21:08:21 +0200 (CEST)
Received: from bochs.com (209-67-232-141.bst0.flashcom.net [209.67.232.141])
	by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id MAA01679
	for <freemware@fastxs.net>; Tue, 17 Aug 1999 12:07:55 -0700 (PDT)
Message-ID: <37B9B30F.2DBB2B54@bochs.com>
Date: Tue, 17 Aug 1999 15:07:59 -0400
From: Kevin Lawton <kevin@bochs.com>
Organization: Bochs Software Company
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: freemware@fastxs.net
Subject: First FreeMWare release!
Content-Type: multipart/mixed;
 boundary="------------CD1214F931FF017AD0AF55AE"
Sender: owner-freemware@fastxs.net
Precedence: bulk
Reply-To: freemware@fastxs.net
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.
--------------CD1214F931FF017AD0AF55AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
--------------CD1214F931FF017AD0AF55AE
Content-Type: text/plain; charset=us-ascii;
 name="fmw-990817b.README"
Content-Disposition: inline;
 filename="fmw-990817b.README"
Content-Transfer-Encoding: 7bit

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?

--------------CD1214F931FF017AD0AF55AE--





--------------9A8E440C3DAFAA4FB2310FCB--



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37B9D682.2C9D9979>