Deos On Virtual Machine Project

From Deos
Jump to navigationJump to search

Getting Deos running on a virtual machine

News

Background

Other individuals have made some progress trying to get deos to run on a virtual machine. Both vmware and bochs have been tried.

  • Bob Coggeshall (a Deos user) was working vmware. He managed to bring the kernel up and run PCI scanner to detect the network card. As luck would have it vmware simulates a lance card. He got stumped when the system tick failed to come in. There was a discussion between him and some Deos maintainers that suggested he modify the intelpc pal to use the timer on the APIC instead of the COM port as the source of the system tick. But he never got around to making the necessary PAL changes.
  • JBR and DI worked on getting Deos up and running on bochs. They where able to get Deos up and running (including the system tick) but given the bochs simulates a NE2000 compatible network card (Real Tech 8029), Deos does not have a network driver for that card, and there was no funding so it stopped there.

What I am doing

I started with vmware mainly because it seemed a shorter path to joy to modify the PAL to use the APIC rather then writing a new network driver. I quickly was able to get to the point Bob had reached (an hour or so). I fiddled around with the serial port settings with the hopes that it had been user error that caused the problem, no such luck. So I started to research using the APIC, this turned into a dead end. vmware simulates whatever CPU you are running it on so if the processor does not have an APIC then you are out. Given this and the fact that vmware has no documentation to help you get an unsupported OS up and running I gave up on vmware for now. I was thinking that maybe what is needed is to setup a client/server relationship via the serial port with a windows application that stimulates the system tick. I did not pursue this because I could not find any documentation in vmware of how the windows app is expected to hook up to the simulated serial port.

Next I started looking at bochs. With a little bit of help from DI (he had to tell me to disable the floppy boot signature check) I was able to get Deos up and running. The next step was to make it so the simulated network card was present. This proved to be much harder then it sounds (and will probably be a major pain for our users). The niclist.exe that comes with bocks would not work so off to the bochs web page I went reading all of the user help on this subject I could find. I found a vbs script that someone had written that looks in the registry so I tried that and it didn't work. I looked at my registry and discovered that the "path" in my registry was slightly different so I modified the script and got it working. Next discovered that WinPcap was needed to run niclist and bochs with the network card (funny I do not remember seeing that in any of the documentation). First I tried version 3.01a and niclist still did not work. Next I tried 3.0 no worky. Then I found help indicating 2.3 was the version it worked with so I tried that. Again, no worky. Getting very tired of resetting my system, I found help indicating 3.0 had worked with XP so out of desperation I decided to give it one more try. To my surprise Bochs worked but netlist still did not. I'm guessing that the first time I tried 3.0 was before I got the VBS script working correctly and I only tried niclist. Unless we can get the niclist executable working users will have the same problem I had, I don't believe the VBS script is a solution because MS seems to change the registry format. Another user issue will be the mac address which is required to be set and to be different from all other machines on the network, it is too bad that you can not use a simulated device that only the host OS can talk to. While doing this I have uncovered a bug in bochs that is a bit of a pain, if you issue a reset the COM port that we use for the tick stops working.

Now I am currently working on the NE2000 network driver, this may take me a while seeing as how I have never written a network driver.

Well I'm no longer working on the NE2000 network driver. No, it is not done. I decided to take a little detour and try virtualPC, when I discovered it had the same tick issue that vmware had (see below) I decided that I needed to push a little more on the tick issue. I read the pal code and I noticed a comment from AL that said something about writing 2 bytes to the COM port at startup so I thought "couldn't hurt". This change fixed the bochs reset issue and allowed ~9 ticks to come in on vmware and ~40 on virtualPC. So I read the UART documentation. After 5 or 6 reads I understood how the pal tick works and I was able to conclude that once in a while the virtual environments are dropping the writes to the COM ports (I have no clue why). I modified the tickRefresh() function as follows and it totally worked on all platforms:

static void tickRefresh(void)
{
 // Send Character to setup next interrupt.
 BYTE lineStatus;
 do
 {
   outPortByte(COM_data,0x55);
   lineStatus = inPortByte(COM_Line_Status);
 }
 while(lineStatus & 0x20); // For some reason writes are dropped some times.  Keep writing until it takes.
}

The next Issue I ran into is for some reason the PCI scanner reports a different IRQ (11) for the network card then gets used when network is loaded (9), go figure. Also the DHCP server that is used by vmware when in 'host only' mode (network communication only works between the host and the simulated target) does not report a router IP address and so network will not accept it's responses. The result of this is if using 'host only' mode you must use a static IP (not really a big deal). In 'bridged' mode (the target gets it's own IP on the LAN) it works just fine. In 'NAT' mode (the target shares the hosts LAN IP) it works as well but I am not sure why you would want to do this. I'm guessing the initial config will be to use 'host mode' and set the IP address up to be the default $DESK_IP_ADDR. The virtual machine seems like it will be a good tool for training and can be used for free by people who just want to check out Deos (vmware lets you try it free for 30 days virtualPC is free for 45 days). It has limited usefulness as a development environment but will work ok if you don't care that much about budgets. The one disappointment I have is I had hoped that the virtual machine could act as an emulator to help with kernel debugging but neither vmware nor virtualPC seem to have this capability. I do not know if bochs has this capability, if it does we may want to consider a NE2000 driver for our use (bochs seems too difficult to set up for the average user).

I started to write the How-To and started to realize that the limitations that the COM tick where adding up to be annoying (1- The tick was not in sync with the thread timer (because the tick was external it would keep coming in even if windows swapped out vmware the rest of the time) 2-COM1 must be available on the host machine 3-Only 1 virtual Deos running at a time). So I started to research using a pipe. After reading all (2 paragraphs) of the documentation about pipes that comes with vmware I decided to poke around the vmware web page when I came across this white paper on time keeping and vmware. This paper documented the one thing I had been looking for and that was the APIC was simulated on all virtual CPU's. Armed with that information and the IA-32 Intel Architecture Software Developer's Manual volume 3, I was able to write vmware PAL that uses the APIC as the system tick.

Other Possibilities

During this process I have come across some other virtual machine's:

  • virtualPC - A MS product. I downloaded the trial version and it too had the lack of tick problem, here again the external program option may work. It seems to have better documentation on what a "pipe" is. The simulated network card is a Digital Equipment Corporation DC21140, we do not have an x86 driver for this card but DI tells me that it is the same as the tulip driver we use for Mac so maybe with a little work we could have one. One nice feature of virtualPC is it has a local network option where only the host and other virtualPC can talk (no need to get on the corporate LAN).
  • QEMU - A shareware product that looks promising but it only runs under Linux. It has the ability to simulate an x86 and a PPC but give the Linux only support at this time probably not a good choice.
  • Serenity Virtual Station - This is an IBM product there is not much documentation to go on here but what I do know is it simulates the NE2000 as well so if the network configuration issue on bochs can't be solved maybe this is a possibility.
  • XEN - An open source version of a commercial package. The folks here seemed to think it had good potential.
  • Parallels - A company offering a product similar to VMware, except it's for Intel based Macs running OS X.