trunk/doc/technical.html

<html><head><title>GXemul documentation: Technical details</title>
<meta name="robots" content="noarchive,nofollow,noindex"></head>
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
<table border=0 width=100% bgcolor="#d0d0d0"><tr>
<td width=100% align=center valign=center><table border=0 width=100%><tr>
<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
<b>GXemul documentation:</b></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<font color="#000000" size="6"><b>Technical details</b>
</font></td></tr></table></td></tr></table><p>

<!--

$Id: technical.html,v 1.51 2005/06/04 22:47:49 debug Exp $

Copyright (C) 2004-2005  Anders Gavare.  All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products
   derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

-->


<a href="./">Back to the index</a>

<p><br>
<h2>Technical details</h2>

<p>
This page describes some of the internals of GXemul.

<p>
<font color="#e00000"><b>NOTE: This page is probably not
very up-to-date by now.</b></font>

<p>
<ul>
  <li><a href="#overview">Overview</a>
  <li><a href="#speed">Speed</a>
  <li><a href="#net">Networking</a>
  <li><a href="#devices">Emulation of hardware devices</a>
  <li><a href="#regtest">Regression tests</a>
</ul>


<p><br>
<a name="overview"></a>
<h3>Overview</h3>

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

<p>
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).

<p>
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.

<p>
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.

<p>
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.


<p><br>
<a name="speed"></a>
<h3>Speed</h3>

There are two modes in which the emulator can run, <b>a</b>) a straight forward 
loop which fetches one instruction from emulated RAM and executes it
(described in the previous section), and <b>b</b>)
using dynamic binary translation.

<p>
Mode <b>a</b> is very slow. On a 2.8 GHz Intel Xeon host the resulting 
emulated machine is rougly equal to a 7 MHz R3000 (or a 3.5 MHz R4000). 
The actual performance varies a lot, maybe between 5 and 10 million 
instructions per second, depending on workload.

<p>
Mode <b>b</b> ("bintrans") is still to be considered experimental, but 
gives higher performance than mode <b>a</b>. It translates MIPS machine 
code into machine code that can be executed on the host machine 
on-the-fly. The translation itself obviously takes some time, but this is 
usually made up for by the fact that the translated code chunks are 
executed multiple times.
To run the emulator with binary translation enabled, just add 
<tt><b>-b</b></tt> to the command line.

<p>
Only small pieces of MIPS machine code are translated, usually the size of 
a function, or less. There is no "intermediate representation" code, so 
all translations are done directly from MIPS to host machine code.

<p>
The default bintrans cache size is 16 MB, but you can change this by adding
<tt>-DDEFAULT_BINTRANS_SIZE_IN_MB=<i>xx</i></tt> to your CFLAGS environment
variable before running the configure script, or by using the
<tt>bintrans_size()</tt> configuration file option when running the emulator.

<p>
By default, an emulated OS running under DECstation emulation which listens to
interrupts from the mc146818 clock will get interrupts that are close to the
host's clock. That is, if the emulated OS says it wants 100 interrupts per
second, it will get approximately 100 interrupts per real second.

<p>
There is however a <tt><b>-I</b></tt> option, which sets the number of
emulated cycles per seconds to a fixed value. Let's say you wish to make the
emulated OS think it is running on a 40 MHz DECstation, and not a 7 MHz one,
then you can add <tt><b>-I 40000000</b></tt> to the command line. This will not
make the emulation faster, of course. It might even make it seem slower; for
example, if NetBSD/pmax waits 2 seconds for SCSI devices to settle during
bootup, those 2 seconds will take 2*40000000 cycles (which will take more 
time than 2*7000000).

<p>
The <b><tt>-I</tt></b> option is also necessary if you want to run
deterministic experiments, if a mc146818 (or similar) device is present.

<p>
Some emulators make claims such as "x times slowdown," but in the case of
GXemul, the host is often not a MIPS-based machine, and hence comparing
one MIPS instruction to a host instruction doesn't work. Performance depends on
a lot of factors, including (but not limited to) host architecture, host speed,
which compiler and compiler flags were used to build GXemul, what the
workload is, and so on. For example, if an emulated operating system tries
to read a block from disk, from its point of view the read was instantaneous
(no waiting). So 1 MIPS in an emulated OS might have taken more than one
million instructions on a real machine.  Because of this, imho it is best 
to measure performance as the actual (real-world) time it takes to perform 
a task with the emulator.


<p><br>
<a name="net"></a>
<h3>Networking</h3>

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.

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

<ol>
  <li>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:
        <ul>
          <li>Requires <i>direct</i> access to the host's NIC, which
                means on most platforms that the emulator cannot be
                run as a normal user!
          <li>Reduced portability, as not every host operating system
                uses the same programming interface for dealing with
                hardware ethernet controllers directly.
          <li>When run on a switched network, it might be problematic to
                connect from the emulated OS to the OS running on the
                host, as packets sent out on the host's NIC are not
                received by itself. (?)
          <li>All specific networking protocols will be handled by the
                physical network.
        </ul>
  <p>
  or
  <p>
  <li>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:
        <ul>
          <li>Each packet type sent out on the emulated NIC must be handled.
                This means that I have to do a lot of coding.
                (I like this, because it gives me an opportunity to
                learn about networking protocols.)
          <li>By not relying on access to the host's NIC directly,
                portability is maintained. (It would be sad if the networking
                portion of a portable emulator isn't as portable as the
                rest of the emulator.)
          <li>The emulator can be run as a normal user process, does
                not require root privilegies.
          <li>Connecting from the emulated OS to the host's OS should
                not be problematic.
          <li>The emulated OS will experience the network just as a single
                machine behind a NAT gateway/firewall would. The emulated
                OS is thus automatically protected from the outside world.
        </ul>
</ol>

<p>
Some emulators/simulators use the first approach, while others use the 
second. I think that SIMH and QEMU are examples of emulators using the 
first and second approach, respectively.

<p>
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 5000/200
emulation (-E dec -e 3max):

<p>
<ul>
  <li>ARP requests sent out from the emulated NIC are interpreted,
        and converted to ARP responses. (This is used by the emulated OS
        to find out the MAC address of the gateway.)
  <li>ICMP echo requests (that is the kind of packet produced by the
        <b><tt>ping</tt></b> program) are interpreted and converted to ICMP echo
        replies, <i>regardless of the IP address</i>. This means that
        running ping from within the emulated OS will <i>always</i>
        receive a response. The ping packets never leave the emulated
        environment.
  <li>UDP packets are interpreted and passed along to the outside world.
        If the emulator receives an UDP packet from the outside world, it
        is converted into an UDP packet for the emulated OS. (This is not
        implemented very well yet, but seems to be enough for nameserver
        lookups, tftp file transfers, and NFS mounts using UDP.)
  <li>TCP packets are interpreted one at a time, similar to how UDP 
        packets are handled (but more state is kept for each connection).
        <font color="#ff0000">NOTE: Much of the TCP handling code is very
        ugly and hardcoded.</font>
<!--
  <li>RARP is not implemented yet. (I haven't needed it so far.)
-->
</ul>

<p>
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 
usually has a fixed IPv4 address of <tt>10.0.0.254</tt>. An OS running in 
the emulator would usually have an address of the form <tt>10.x.x.x</tt>;
a typical choice would be <tt>10.0.0.1</tt>.

<p>
Inside emulated NetBSD/pmax or OpenBSD/pmax, running the following 
commands should configure the emulated NIC:
<pre>
        # <b>ifconfig le0 10.0.0.1</b>
        # <b>route add default 10.0.0.254</b>
        add net default: gateway 10.0.0.254
</pre>

<p>
If you want nameserver lookups to work, you need a valid /etc/resolv.conf 
as well:
<pre>
        # <b>echo nameserver 129.16.1.3 > /etc/resolv.conf</b>
</pre>
(But replace <tt>129.16.1.3</tt> with the actual real-world IP address of 
your nearest nameserver.)

<p>
Now, host lookups should work:
<pre>
        # <b>host -a www.netbsd.org</b>
        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
</pre>

<p>
At this point, UDP and TCP should (mostly) work.

<p>
Here is an example of how to configure a server machine and an emulated 
client machine for sharing files via NFS:

<p>
(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.)

<p>
<ul>
  <li>On the server, add a line to your /etc/exports file, exporting
        the files you wish to use in the emulator:<pre>
        <b>/tftpboot -mapall=nobody -ro 123.11.22.33</b>
</pre>
        where 123.11.22.33 is the IP address of the machine running the
        emulator process, as seen from the outside world.
  <p>
  <li>Then start up the programs needed to serve NFS via UDP. Note the
        -n argument to mountd. This is needed to tell mountd to accept
        connections from unprivileged ports (because the emulator does
        not need to run as root).<pre>
        # <b>portmap</b>
        # <b>nfsd -u</b>       &lt;--- u for UDP
        # <b>mountd -n</b>
</pre>
  <li>In the guest OS in the emulator, once you have ethernet and IPv4
        configured so that you can use UDP, mounting the filesystem
        should now be possible:  (this example is for NetBSD/pmax
        or OpenBSD/pmax)<pre>
        # <b>mount -o ro,-r=1024,-w=1024,-U,-3 my.server.com:/tftpboot /mnt</b>
    or
        # <b>mount my.server.com:/tftpboot /mnt</b>
</pre>
        If you don't supply the read and write sizes, there is a risk
        that the default values are too large. The emulator currently
        does not handle fragmentation/defragmentation of <i>outgoing</i>
        packets, so going above the ethernet frame size (1518) is a very
        bad idea. Incoming packets (reading from nfs) should work, though,
        for example during an NFS install.
</ul>

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.


<p><br>
<a name="devices"></a>
<h3>Emulation of hardware devices</h3>

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, or when adding devices to a 
machine using the <b>device()</b> command in configuration files.

<p>
<font color="#ff0000">NOTE: 2005-02-26: I'm currently rewriting the
device registry subsystem.</font>

<p>
(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.)

<p>
Each device should have the following:

<p>
<ul>
  <li>A devinit function in dev_foo.c. It would typically look
        something like this:
<pre>
        /*
         *  devinit_foo():
         */
        int devinit_foo(struct devinit *devinit)
        {
                struct foo_data *d = malloc(sizeof(struct foo_data));

                if (d == NULL) {
                        fprintf(stderr, "out of memory\n");
                        exit(1);
                }
                memset(d, 0, sizeof(struct foon_data));

                /*
                 *  Set up stuff here, for example fill d with useful
                 *  data. devinit contains settings like address, irq_nr,
                 *  and other things.
                 *
                 *  ...
                 */
        
                memory_device_register(devinit->machine->memory, devinit->name,
                    devinit->addr, DEV_FOO_LENGTH,
                    dev_foo_access, (void *)d, MEM_DEFAULT, NULL);
        
                /*  This should only be here if the device
                    has a tick function:  */
                machine_add_tickfunction(machine, dev_foo_tick, d,
                    FOO_TICKSHIFT);

                /*  Return 1 if the device was successfully added.  */
                return 1;       
        }       
</pre><br>

  <li>At the top of dev_foo.c, the foo_data struct should be defined.
<pre>
        struct foo_data {
                int     irq_nr;
                /*  ...  */
        }
</pre><br>

  <li>If foo has a tick function (that is, something that needs to be
        run at regular intervals) then FOO_TICKSHIFT and a tick function
        need to be defined as well:
<pre>
        #define FOO_TICKSHIFT           10

        void dev_foo_tick(struct cpu *cpu, void *extra)
        {
                struct foo_data *d = (struct foo_data *) extra;

                if (.....)
                        cpu_interrupt(cpu, d->irq_nr);
                else
                        cpu_interrupt_ack(cpu, d->irq_nr);
        }
</pre><br>

  <li>And last but not least, the device should have an access function.
        The access function is called whenever there is a load or store
        to an address which is in the device' memory mapped region.
<pre>
        int dev_foo_access(struct cpu *cpu, struct memory *mem,
            uint64_t relative_addr, unsigned char *data, size_t len,
            int writeflag, void *extra)
        {
                struct foo_data *d = extra;
                uint64_t idata = 0, odata = 0;

                idata = memory_readmax64(cpu, data, len);
                switch (relative_addr) {
                /* .... */
                }

                if (writeflag == MEM_READ)
                        memory_writemax64(cpu, data, len, odata);

                /*  Perhaps interrupts need to be asserted or
                    deasserted:  */
                dev_foo_tick(cpu, extra);

                /*  Return successfully.  */
                return 1;
        }
</pre><br>
</ul>

<p>
The return value of the access function has until 2004-07-02 been a 
true/false value; 1 for success, or 0 for device access failure. A device 
access failure (on MIPS) will result in a DBE exception.

<p>
Some devices are converted to support arbitrary memory latency
values. The return value is 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.

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


<p><br>
<a name="regtest"></a>
<h3>Regression tests</h3>

In order to make sure that the emulator actually works like it is supposed 
to, it must be tested. For this purpose, there is a simple regression 
testing framework in the <tt>tests/</tt> directory.

<p>
<i>NOTE:  The regression testing framework is basically just a skeleton so far.
Regression tests are very good to have. However, the fact that complete
operating systems can run in the emulator indicate that the emulation is
probably not too incorrect. This makes it less of a priority to write 
regression tests.</i>

<p>
To run all the regression tests, type <tt>make regtest</tt>. Each assembly 
language file matching the pattern <tt>test_*.S</tt> will be compiled and 
linked into a 64-bit MIPS ELF (using a gcc cross compiler), and run in the 
emulator. If everything goes well, you should see something like this:

<pre>
        $ make regtest
        cd tests; make run_tests; cd ..
        gcc33 -Wall -fomit-frame-pointer -fmove-all-movables -fpeephole -O2 
                -mcpu=ev5 -I/usr/X11R6/include -lm -L/usr/X11R6/lib -lX11  do_tests.c
                -o do_tests
        do_tests.c: In function `main':
        do_tests.c:173: warning: unused variable `s'
        /var/tmp//ccFOupvD.o: In function `do_tests':
        /var/tmp//ccFOupvD.o(.text+0x3a8): warning: tmpnam() possibly used
                unsafely; consider using mkstemp()
        mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns -mips64 
                -mabi=64 test_common.c -c -o test_common.o
        ./do_tests "mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns 
                -mips64 -mabi=64" "mips64-unknown-elf-as -mabi=64 -mips64" 
                "mips64-unknown-elf-ld -Ttext 0xa800000000030000 -e main 
                --oformat=elf64-bigmips" "../gxemul"

        Starting tests:
          test_addu.S (-a)
          test_addu.S (-a -b)
          test_clo_clz.S (-a)
          test_clo_clz.S (-a -b)
          ..
          test_unaligned.S (-a)
          test_unaligned.S (-a -b)

        Done. (12 tests done)
            PASS:     12
            FAIL:      0

        ----------------

          All tests OK

        ----------------
</pre>

<p>
Each test writes output to stdout, and there is a <tt>test_*.good</tt> for 
each <tt>.S</tt> file which contains the wanted output. If the actual 
output matches the <tt>.good</tt> file, then the test passes, otherwise it 
fails.

<p>
Read <tt>tests/README</tt> for more information.


</body>
</html>