trunk/doc/technical.html

<html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;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>Gavare's eXperimental Emulator:</b></font><br>
<font color="#000000" size="6"><b>Technical details</b>
</font></td></tr></table></td></tr></table><p>

<!--

$Id: technical.html,v 1.76 2007/06/15 18:07:08 debug Exp $

Copyright (C) 2004-2007  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>
<ul>
  <li><a href="#speed">Speed and emulation modes</a>
  <li><a href="#net">Networking</a>
  <li><a href="#devices">Emulation of hardware devices</a>
</ul>


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

So, how fast is GXemul? There is no short answer to this. There is 
especially no answer to the question <b>What is the slowdown factor?</b>, 
because the host architecture and emulated architecture can usually not be 
compared just like that.

<p>Performance depends on several factors, including (but not limited to)  
host architecture, target architecture, host clock speed, which compiler
and compiler flags were used to build the emulator, what the workload is,
what additional runtime flags are given to the emulator, and so on.

<p>Devices are generally not timing-accurate: 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.

<p>Also, if the emulator says it has executed 1 million instructions, and 
the CPU family in question was capable of scalar execution (i.e. one cycle 
per instruction), it might still have taken more than 1 million cycles on 
a real machine because of cache misses and similar micro-architectural 
penalties that are not simulated by GXemul.

<p>Because of these issues, it is in my opinion best to measure
performance as the actual (real-world) time it takes to perform a task
with the emulator, e.g.:

<ul>
  <li>"How long does it take to install NetBSD onto a disk image?"
  <li>"How long does it take to compile XYZ inside NetBSD
        in the emulator?".
</ul>

<p>So, how fast is it? :-)&nbsp;&nbsp;&nbsp;Answer: it varies.


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

<font color="#ff0000">NOTE/TODO: This section is very old.</font>

<p>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 called <tt>dev_*.c</tt> in the 
<a href="../src/devices/"><tt>src/devices/</tt></a> directory is
responsible for one hardware device. These are used from
<a href="../src/machines/"><tt>src/machines</tt></a><tt>/machine_*.c</tt>,
when initializing which hardware a particular machine model will be using,
or when adding devices to a machine using the <tt>device()</tt> command in
<a href="configfiles.html">configuration files</a>.

<p>(I'll be using the name "<tt>foo</tt>" 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 <tt>devinit</tt> function in <tt>src/devices/dev_foo.c</tt>. It
        would typically look something like this:
<pre>
        DEVINIT(foo)
        {
                struct foo_data *d;

                CHECK_ALLOCATION(d = malloc(sizeof(struct foo_data)));
                memset(d, 0, sizeof(struct foo_data));

                /*
                 *  Set up stuff here, for example fill d with useful
                 *  data. devinit contains settings like address, irq path,
                 *  and other things.
                 *
                 *  ...
                 */

                INTERRUPT_CONNECT(devinit->interrupt_path, d->irq);
        
                memory_device_register(devinit->machine->memory, devinit->name,
                    devinit->addr, DEV_FOO_LENGTH,
                    dev_foo_access, (void *)d, DM_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>

        <p><tt>DEVINIT(foo)</tt> is defined as <tt>int devinit_foo(struct devinit *devinit)</tt>,
        and the <tt>devinit</tt> argument contains everything that the device driver's
        initialization function needs.

  <p>
  <li>At the top of <tt>dev_foo.c</tt>, the <tt>foo_data</tt> struct
        should be defined.
<pre>
        struct foo_data {
                struct interrupt        irq;
                /*  ...  */
        }
</pre><br>
        (There is an exception to this rule; some legacy code and other
        ugly hacks have their device structs defined in
        <tt>src/include/devices.h</tt> instead of <tt>dev_foo.c</tt>.
        New code should not add stuff to <tt>devices.h</tt>.)
  <p>
  <li>If <tt>foo</tt> has a tick function (that is, something that needs to be
        run at regular intervals) then <tt>FOO_TICKSHIFT</tt> and a tick 
        function need to be defined as well:
<pre>
        #define FOO_TICKSHIFT           14

        DEVICE_TICK(foo)
        {
                struct foo_data *d = extra;

                if (.....)
                        INTERRUPT_ASSERT(d->irq);
                else
                        INTERRUPT_DEASSERT(d->irq);
        }
</pre><br>

  <li>Does this device belong to a standard bus?
        <ul>
          <li>If this device should be detectable as a PCI device, then
                glue code should be added to
                <tt>src/devices/bus_pci.c</tt>.
          <li>If this is a legacy ISA device which should be usable by
                any machine which has an ISA bus, then the device should
                be added to <tt>src/devices/bus_isa.c</tt>.
        </ul>
  <p>
  <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. To
        simplify things a little, a macro <tt>DEVICE_ACCESS(x)</tt>
        is expanded into<pre>
        int dev_x_access(struct cpu *cpu, struct memory *mem,
            uint64_t relative_addr, unsigned char *data, size_t len,
            int writeflag, void *extra)
</pre>  The access function can look like this:
<pre>
        DEVICE_ACCESS(foo)
        {
                struct foo_data *d = extra;
                uint64_t idata = 0, odata = 0;

                if (writeflag == MEM_WRITE)
                        idata = memory_readmax64(cpu, data, len);

                switch (relative_addr) {

                /*  Handle accesses to individual addresses within
                    the device here.  */

                /*  ...  */

                }

                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.


</body>
</html>
1	<html><head><title>Gavare's eXperimental Emulator:   Technical details</title>
2	<meta name="robots" content="noarchive,nofollow,noindex"></head>
3	<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
4	<table border=0 width=100% bgcolor="#d0d0d0"><tr>
5	<td width=100% align=center valign=center><table border=0 width=100%><tr>
6	<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
7	<b>Gavare's eXperimental Emulator:</b></font><br>
8	<font color="#000000" size="6"><b>Technical details</b>
9	</font></td></tr></table></td></tr></table><p>
10
11	<!--
12
13	$Id: technical.html,v 1.76 2007/06/15 18:07:08 debug Exp $
14
15	Copyright (C) 2004-2007 Anders Gavare. All rights reserved.
16
17	Redistribution and use in source and binary forms, with or without
18	modification, are permitted provided that the following conditions are met:
19
20	1. Redistributions of source code must retain the above copyright
21	notice, this list of conditions and the following disclaimer.
22	2. Redistributions in binary form must reproduce the above copyright
23	notice, this list of conditions and the following disclaimer in the
24	documentation and/or other materials provided with the distribution.
25	3. The name of the author may not be used to endorse or promote products
26	derived from this software without specific prior written permission.
27
28	THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
29	ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
30	IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
31	ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
32	FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
33	DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
34	OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
35	HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
36	LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
37	OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
38	SUCH DAMAGE.
39
40	-->
41
42
43
44	<a href="./">Back to the index</a>
45
46	<p><br>
47	<h2>Technical details</h2>
48
49	<p>This page describes some of the internals of GXemul.
50
51	<p>
52	<ul>
53	<li><a href="#speed">Speed and emulation modes</a>
54	<li><a href="#net">Networking</a>
55	<li><a href="#devices">Emulation of hardware devices</a>
56	</ul>
57
58
59
60
61
62
63	<p><br>
64	<a name="speed"></a>
65	<h3>Speed and emulation modes</h3>
66
67	So, how fast is GXemul? There is no short answer to this. There is
68	especially no answer to the question <b>What is the slowdown factor?</b>,
69	because the host architecture and emulated architecture can usually not be
70	compared just like that.
71
72	<p>Performance depends on several factors, including (but not limited to)
73	host architecture, target architecture, host clock speed, which compiler
74	and compiler flags were used to build the emulator, what the workload is,
75	what additional runtime flags are given to the emulator, and so on.
76
77	<p>Devices are generally not timing-accurate: for example, if an emulated
78	operating system tries to read a block from disk, from its point of view
79	the read was instantaneous (no waiting). So 1 MIPS in an emulated OS might
80	have taken more than one million instructions on a real machine.
81
82	<p>Also, if the emulator says it has executed 1 million instructions, and
83	the CPU family in question was capable of scalar execution (i.e. one cycle
84	per instruction), it might still have taken more than 1 million cycles on
85	a real machine because of cache misses and similar micro-architectural
86	penalties that are not simulated by GXemul.
87
88	<p>Because of these issues, it is in my opinion best to measure
89	performance as the actual (real-world) time it takes to perform a task
90	with the emulator, e.g.:
91
92	<ul>
93	<li>"How long does it take to install NetBSD onto a disk image?"
94	<li>"How long does it take to compile XYZ inside NetBSD
95	in the emulator?".
96	</ul>
97
98	<p>So, how fast is it? :-)   Answer: it varies.
99
100
101
102
103
104
105
106	<p><br>
107	<a name="net"></a>
108	<h3>Networking</h3>
109
110	<font color="#ff0000">NOTE/TODO: This section is very old.</font>
111
112	<p>Running an entire operating system under emulation is very interesting
113	in itself, but for several reasons, running a modern OS without access to
114	TCP/IP networking is a bit akward. Hence, I feel the need to implement
115	TCP/IP (networking) support in the emulator.
116
117	<p>
118	As far as I have understood it, there seems to be two different ways to go:
119
120	<ol>
121	<li>Forward ethernet packets from the emulated ethernet controller to
122	the host machine's ethernet controller, and capture incoming
123	packets on the host's controller, giving them back to the
124	emulated OS. Characteristics are:
125	<ul>
126	<li>Requires <i>direct</i> access to the host's NIC, which
127	means on most platforms that the emulator cannot be
128	run as a normal user!
129	<li>Reduced portability, as not every host operating system
130	uses the same programming interface for dealing with
131	hardware ethernet controllers directly.
132	<li>When run on a switched network, it might be problematic to
133	connect from the emulated OS to the OS running on the
134	host, as packets sent out on the host's NIC are not
135	received by itself. (?)
136	<li>All specific networking protocols will be handled by the
137	physical network.
138	</ul>
139	<p>
140	or
141	<p>
142	<li>Whenever the emulated ethernet controller wishes to send a packet,
143	the emulator looks at the packet and creates a response. Packets
144	that can have an immediate response never go outside the emulator,
145	other packet types have to be converted into suitable other
146	connection types (UDP, TCP, etc). Characteristics:
147	<ul>
148	<li>Each packet type sent out on the emulated NIC must be handled.
149	This means that I have to do a lot of coding.
150	(I like this, because it gives me an opportunity to
151	learn about networking protocols.)
152	<li>By not relying on access to the host's NIC directly,
153	portability is maintained. (It would be sad if the networking
154	portion of a portable emulator isn't as portable as the
155	rest of the emulator.)
156	<li>The emulator can be run as a normal user process, does
157	not require root privilegies.
158	<li>Connecting from the emulated OS to the host's OS should
159	not be problematic.
160	<li>The emulated OS will experience the network just as a single
161	machine behind a NAT gateway/firewall would. The emulated
162	OS is thus automatically protected from the outside world.
163	</ul>
164	</ol>
165
166	<p>
167	Some emulators/simulators use the first approach, while others use the
168	second. I think that SIMH and QEMU are examples of emulators using the
169	first and second approach, respectively.
170
171	<p>
172	Since I have choosen the second kind of implementation, I have to write
173	support explicitly for any kind of network protocol that should be
174	supported. As of 2004-07-09, the following has been implemented and seems
175	to work under at least NetBSD/pmax and OpenBSD/pmax under DECstation 5000/200
176	emulation (-E dec -e 3max):
177
178	<p>
179	<ul>
180	<li>ARP requests sent out from the emulated NIC are interpreted,
181	and converted to ARP responses. (This is used by the emulated OS
182	to find out the MAC address of the gateway.)
183	<li>ICMP echo requests (that is the kind of packet produced by the
184	<b><tt>ping</tt></b> program) are interpreted and converted to ICMP echo
185	replies, <i>regardless of the IP address</i>. This means that
186	running ping from within the emulated OS will <i>always</i>
187	receive a response. The ping packets never leave the emulated
188	environment.
189	<li>UDP packets are interpreted and passed along to the outside world.
190	If the emulator receives an UDP packet from the outside world, it
191	is converted into an UDP packet for the emulated OS. (This is not
192	implemented very well yet, but seems to be enough for nameserver
193	lookups, tftp file transfers, and NFS mounts using UDP.)
194	<li>TCP packets are interpreted one at a time, similar to how UDP
195	packets are handled (but more state is kept for each connection).
196	<font color="#ff0000">NOTE: Much of the TCP handling code is very
197	ugly and hardcoded.</font>
198	<!--
199	<li>RARP is not implemented yet. (I haven't needed it so far.)
200	-->
201	</ul>
202
203	<p>
204	The gateway machine, which is the only "other" machine that the emulated
205	OS sees on its emulated network, works as a NAT-style firewall/gateway. It
206	usually has a fixed IPv4 address of <tt>10.0.0.254</tt>. An OS running in
207	the emulator would usually have an address of the form <tt>10.x.x.x</tt>;
208	a typical choice would be <tt>10.0.0.1</tt>.
209
210	<p>
211	Inside emulated NetBSD/pmax or OpenBSD/pmax, running the following
212	commands should configure the emulated NIC:
213	<pre>
214	# <b>ifconfig le0 10.0.0.1</b>
215	# <b>route add default 10.0.0.254</b>
216	add net default: gateway 10.0.0.254
217	</pre>
218
219	<p>
220	If you want nameserver lookups to work, you need a valid /etc/resolv.conf
221	as well:
222	<pre>
223	# <b>echo nameserver 129.16.1.3 > /etc/resolv.conf</b>
224	</pre>
225	(But replace <tt>129.16.1.3</tt> with the actual real-world IP address of
226	your nearest nameserver.)
227
228	<p>
229	Now, host lookups should work:
230	<pre>
231	# <b>host -a www.netbsd.org</b>
232	Trying null domain
233	rcode = 0 (Success), ancount=2
234	The following answer is not authoritative:
235	The following answer is not verified as authentic by the server:
236	www.netbsd.org 86400 IN AAAA 2001:4f8:4:7:290:27ff:feab:19a7
237	www.netbsd.org 86400 IN A 204.152.184.116
238	For authoritative answers, see:
239	netbsd.org 83627 IN NS uucp-gw-2.pa.dec.com
240	netbsd.org 83627 IN NS ns.netbsd.org
241	netbsd.org 83627 IN NS adns1.berkeley.edu
242	netbsd.org 83627 IN NS adns2.berkeley.edu
243	netbsd.org 83627 IN NS uucp-gw-1.pa.dec.com
244	Additional information:
245	ns.netbsd.org 83627 IN A 204.152.184.164
246	uucp-gw-1.pa.dec.com 172799 IN A 204.123.2.18
247	uucp-gw-2.pa.dec.com 172799 IN A 204.123.2.19
248	</pre>
249
250	<p>
251	At this point, UDP and TCP should (mostly) work.
252
253	<p>
254	Here is an example of how to configure a server machine and an emulated
255	client machine for sharing files via NFS:
256
257	<p>
258	(This is very useful if you want to share entire directory trees
259	between the emulated environment and another machine. These instruction
260	will work for FreeBSD, if you are running something else, use your
261	imagination to modify them.)
262
263	<p>
264	<ul>
265	<li>On the server, add a line to your /etc/exports file, exporting
266	the files you wish to use in the emulator:<pre>
267	<b>/tftpboot -mapall=nobody -ro 123.11.22.33</b>
268	</pre>
269	where 123.11.22.33 is the IP address of the machine running the
270	emulator process, as seen from the outside world.
271	<p>
272	<li>Then start up the programs needed to serve NFS via UDP. Note the
273	-n argument to mountd. This is needed to tell mountd to accept
274	connections from unprivileged ports (because the emulator does
275	not need to run as root).<pre>
276	# <b>portmap</b>
277	# <b>nfsd -u</b> <--- u for UDP
278	# <b>mountd -n</b>
279	</pre>
280	<li>In the guest OS in the emulator, once you have ethernet and IPv4
281	configured so that you can use UDP, mounting the filesystem
282	should now be possible: (this example is for NetBSD/pmax
283	or OpenBSD/pmax)<pre>
284	# <b>mount -o ro,-r=1024,-w=1024,-U,-3 my.server.com:/tftpboot /mnt</b>
285	or
286	# <b>mount my.server.com:/tftpboot /mnt</b>
287	</pre>
288	If you don't supply the read and write sizes, there is a risk
289	that the default values are too large. The emulator currently
290	does not handle fragmentation/defragmentation of <i>outgoing</i>
291	packets, so going above the ethernet frame size (1518) is a very
292	bad idea. Incoming packets (reading from nfs) should work, though,
293	for example during an NFS install.
294	</ul>
295
296	The example above uses read-only mounts. That is enough for things like
297	letting NetBSD/pmax or OpenBSD/pmax install via NFS, without the need for
298	a CDROM ISO image. You can use a read-write mount if you wish to share
299	files in both directions, but then you should be aware of the
300	fragmentation issue mentioned above.
301
302
303
304
305
306
307
308	<p><br>
309	<a name="devices"></a>
310	<h3>Emulation of hardware devices</h3>
311
312	Each file called <tt>dev_*.c</tt> in the
313	<a href="../src/devices/"><tt>src/devices/</tt></a> directory is
314	responsible for one hardware device. These are used from
315	<a href="../src/machines/"><tt>src/machines</tt></a><tt>/machine_*.c</tt>,
316	when initializing which hardware a particular machine model will be using,
317	or when adding devices to a machine using the <tt>device()</tt> command in
318	<a href="configfiles.html">configuration files</a>.
319
320	<p>(I'll be using the name "<tt>foo</tt>" as the name of the device in all
321	these examples. This is pseudo code, it might need some modification to
322	actually compile and run.)
323
324	<p>Each device should have the following:
325
326	<p>
327	<ul>
328	<li>A <tt>devinit</tt> function in <tt>src/devices/dev_foo.c</tt>. It
329	would typically look something like this:
330	<pre>
331	DEVINIT(foo)
332	{
333	struct foo_data *d;
334
335	CHECK_ALLOCATION(d = malloc(sizeof(struct foo_data)));
336	memset(d, 0, sizeof(struct foo_data));
337
338	/*
339	* Set up stuff here, for example fill d with useful
340	* data. devinit contains settings like address, irq path,
341	* and other things.
342	*
343	* ...
344	*/
345
346	INTERRUPT_CONNECT(devinit->interrupt_path, d->irq);
347
348	memory_device_register(devinit->machine->memory, devinit->name,
349	devinit->addr, DEV_FOO_LENGTH,
350	dev_foo_access, (void *)d, DM_DEFAULT, NULL);
351
352	/* This should only be here if the device
353	has a tick function: */
354	machine_add_tickfunction(machine, dev_foo_tick, d,
355	FOO_TICKSHIFT);
356
357	/* Return 1 if the device was successfully added. */
358	return 1;
359	}
360	</pre><br>
361
362	<p><tt>DEVINIT(foo)</tt> is defined as <tt>int devinit_foo(struct devinit *devinit)</tt>,
363	and the <tt>devinit</tt> argument contains everything that the device driver's
364	initialization function needs.
365
366	<p>
367	<li>At the top of <tt>dev_foo.c</tt>, the <tt>foo_data</tt> struct
368	should be defined.
369	<pre>
370	struct foo_data {
371	struct interrupt irq;
372	/* ... */
373	}
374	</pre><br>
375	(There is an exception to this rule; some legacy code and other
376	ugly hacks have their device structs defined in
377	<tt>src/include/devices.h</tt> instead of <tt>dev_foo.c</tt>.
378	New code should not add stuff to <tt>devices.h</tt>.)
379	<p>
380	<li>If <tt>foo</tt> has a tick function (that is, something that needs to be
381	run at regular intervals) then <tt>FOO_TICKSHIFT</tt> and a tick
382	function need to be defined as well:
383	<pre>
384	#define FOO_TICKSHIFT 14
385
386	DEVICE_TICK(foo)
387	{
388	struct foo_data *d = extra;
389
390	if (.....)
391	INTERRUPT_ASSERT(d->irq);
392	else
393	INTERRUPT_DEASSERT(d->irq);
394	}
395	</pre><br>
396
397	<li>Does this device belong to a standard bus?
398	<ul>
399	<li>If this device should be detectable as a PCI device, then
400	glue code should be added to
401	<tt>src/devices/bus_pci.c</tt>.
402	<li>If this is a legacy ISA device which should be usable by
403	any machine which has an ISA bus, then the device should
404	be added to <tt>src/devices/bus_isa.c</tt>.
405	</ul>
406	<p>
407	<li>And last but not least, the device should have an access function.
408	The access function is called whenever there is a load or store
409	to an address which is in the device' memory mapped region. To
410	simplify things a little, a macro <tt>DEVICE_ACCESS(x)</tt>
411	is expanded into<pre>
412	int dev_x_access(struct cpu cpu, struct memory mem,
413	uint64_t relative_addr, unsigned char *data, size_t len,
414	int writeflag, void *extra)
415	</pre> The access function can look like this:
416	<pre>
417	DEVICE_ACCESS(foo)
418	{
419	struct foo_data *d = extra;
420	uint64_t idata = 0, odata = 0;
421
422	if (writeflag == MEM_WRITE)
423	idata = memory_readmax64(cpu, data, len);
424
425	switch (relative_addr) {
426
427	/* Handle accesses to individual addresses within
428	the device here. */
429
430	/* ... */
431
432	}
433
434	if (writeflag == MEM_READ)
435	memory_writemax64(cpu, data, len, odata);
436
437	/* Perhaps interrupts need to be asserted or
438	deasserted: */
439	dev_foo_tick(cpu, extra);
440
441	/* Return successfully. */
442	return 1;
443	}
444	</pre><br>
445	</ul>
446
447	<p>
448	The return value of the access function has until 2004-07-02 been a
449	true/false value; 1 for success, or 0 for device access failure. A device
450	access failure (on MIPS) will result in a DBE exception.
451
452	<p>
453	Some devices are converted to support arbitrary memory latency
454	values. The return value is the number of cycles that the read or
455	write access took. A value of 1 means one cycle, a value of 10 means 10
456	cycles. Negative values are used for device access failures, and the
457	absolute value of the value is then the number of cycles; a value of -5
458	means that the access failed, and took 5 cycles.
459
460	<p>
461	To be compatible with pre-20040702 devices, a return value of 0 is treated
462	by the caller (in <tt>src/memory_rw.c</tt>) as a value of -1.
463
464
465
466
467
468
469	</body>
470	</html>