mips64emul



mips64emul Technical Documentation

This page describes some of the internals of mips64emul. For more general documentation, please read the User Documentation.


Contents:


Overview

In simple terms, mips64emul is just a simple fetch-and-execute loop; an instruction is fetched from memory, and executed.

In reality, a lot of things need to be handled. Before each instruction is executed, the emulator checks to see if any interrupts are asserted which are not masked away. If so, then an INT exception is generated. Exceptions cause the program counter to be set to a specific value, and some of the system coprocessor's registers to be set to values signifying what kind of exception it was (an interrupt exception in this case).

Reading instructions from memory is done through a TLB, a translation lookaside buffer. The TLB on MIPS is software controlled, which means that the program running inside the emulator (for example an operating system kernel) has to take care of manually updating the TLB. Some memory addresses are translated into physical addresses directly, some are translated into valid physical addresses via the TLB, and some memory references are not valid. Invalid memory references cause exceptions.

After an instruction has been read from memory, the emulator checks which opcode it contains and executes the instruction. Executing an instruction usually involves reading some register and writing some register, or perhaps a load from memory (or a store to memory). The program counter is increased for every instruction.

Some memory references point to physical addresses which are not in the normal RAM address space. They may point to hardware devices. If that is the case, then loads and stores are converted into calls to a device access function. The device access function is then responsible for handling these reads and writes. For example, a graphical framebuffer device may put a pixel on the screen when a value is written to it, or a serial controller device may output a character to stdout when written to.


Optimizations

TODO.


Networking

Running an entire operating system under emulation is very interesting in itself, but for several reasons, running a modern OS without access to TCP/IP networking is a bit akward. Hence, I feel the need to implement TCP/IP (networking) support in the emulator.

As far as I have understood it, there seems to be two different ways to go:

  1. Forward ethernet packets from the emulated ethernet controller to the host machine's ethernet controller, and capture incoming packets on the host's controller, giving them back to the emulated OS. Characteristics are:

    or

  2. Whenever the emulated ethernet controller wishes to send a packet, the emulator looks at the packet and creates a response. Packets that can have an immediate response never go outside the emulator, other packet types have to be converted into suitable other connection types (UDP, TCP, etc). Characteristics:
Other emulators that I have heard of seem to use the first one, if they support networking.

Since I have choosen the second kind of implementation, I have to write support explicitly for any kind of network protocol that should be supported. As of 2004-07-09, the following has been implemented and seems to work under at least NetBSD/pmax and OpenBSD/pmax under DECstation -D2 emulation:

The gateway machine, which is the only "other" machine that the emulated OS sees on its emulated network, works as a NAT-style firewall/gateway. It has a fixed IPv4 address of 10.0.0.254. An OS running in the emulator can thus have any 10.x.x.x address; a typical choice would be 10.0.0.1.

Inside emulated NetBSD or OpenBSD, running the following commands should configure the emulated NIC:

	# ifconfig le0 10.0.0.1
	# route add default 10.0.0.254
	add net default: gateway 10.0.0.254
If you want nameserver lookups to work, you need a valid /etc/resolv.conf as well:
	# echo nameserver 129.16.1.3 > /etc/resolv.conf
(But replace 129.16.1.3 with the actual real-world IP address of your nearest nameserver.)

Now, host lookups should work:

	# host -a www.netbsd.org
	Trying null domain
	rcode = 0 (Success), ancount=2
	The following answer is not authoritative:
	The following answer is not verified as authentic by the server:
	www.netbsd.org  86400 IN        AAAA    2001:4f8:4:7:290:27ff:feab:19a7
	www.netbsd.org  86400 IN        A       204.152.184.116
	For authoritative answers, see:
	netbsd.org      83627 IN        NS      uucp-gw-2.pa.dec.com
	netbsd.org      83627 IN        NS      ns.netbsd.org
	netbsd.org      83627 IN        NS      adns1.berkeley.edu
	netbsd.org      83627 IN        NS      adns2.berkeley.edu
	netbsd.org      83627 IN        NS      uucp-gw-1.pa.dec.com
	Additional information:
	ns.netbsd.org   83627 IN        A       204.152.184.164
	uucp-gw-1.pa.dec.com	172799 IN	A	204.123.2.18
	uucp-gw-2.pa.dec.com	172799 IN	A	204.123.2.19
To transfer files via UDP, you can use the tftp program.
	# tftp 12.34.56.78
	tftp> get filename
	Received XXXXXX bytes in X.X seconds
	tftp> quit
	# 
or, to do it non-interactively (with ugly output):
	# echo get filename | tftp 12.34.56.78
	tftp> Received XXXXXX bytes in X.X seconds
	tftp> #
This, of course, requires that you have put the file filename in the root directory of the tftp server (12.34.56.78).

It is also possible to run NFS via UDP. This is very useful if you want to share entire directory trees between the emulated environment and another machine. These instruction will work for FreeBSD, if you are running something else, use your imagination to modify them:

The example above uses read-only mounts. That is enough for things like letting NetBSD/pmax or OpenBSD/pmax install via NFS, without the need for a CDROM ISO image. You can use a read-write mount if you wish to share files in both directions, but then you should be aware of the fragmentation issue mentioned above.

TCP is implemented to some extend, but should not be considered very stable yet. It is enough to let NetBSD/pmax and OpenBSD/pmax install via ftp, though.


Emulation of hardware devices

Each file in the device/ directory is responsible for one hardware device. These are used from src/machine.c, when initializing which hardware a particular machine model will be using. (I'll be using the name 'foo' as the name of the device in all these examples. This is pseudo code, it might need some modification to actually compile and run.)

Each device should have the following:

The return value of the access function has until 20040702 been a true/false value; 1 for success, or 0 for device access failure. A device access failure will be seen as a MIPS DBE exception from the CPU.

Right now I'm converting the devices to support arbitrary memory latency values. The return value is now the number of cycles that the read or write access took. A value of 1 means one cycle, a value of 10 means 10 cycles. Negative values are used for device access failures, and the absolute value of the value is then the number of cycles; a value of -5 means that the access failed, and took 5 cycles.

To be compatible with pre-20040702 devices, a return value of 0 is treated by the caller (in src/memory.c) as a value of -1.


Feedback:

If you have comments, don't hesitate to mail me at md1gavan at mdstud.chalmers.se.