|
This page describes some of the internals of GXemul.
Performance depends on several factors, including (but not limited to) host architecture, host clock speed, which compiler and compiler flags were used to build the emulator, 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.
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.
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. Typical examples would be "How long does it take to install NetBSD?", or "How long does it take to compile XYZ inside NetBSD in the emulator?".
So, how fast is it? :-) Answer: it varies.
The emulation technique used varies depending on which processor type is being emulated. (One of my main goals with GXemul is to experiment with different kinds of emulation, so these might change in the future.)
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:
or
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.
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):
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 10.0.0.254. An OS running in the emulator would usually have an address of the form 10.x.x.x; a typical choice would be 10.0.0.1.
Inside emulated NetBSD/pmax or OpenBSD/pmax, 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
At this point, UDP and TCP should (mostly) work.
Here is an example of how to configure a server machine and an emulated client machine for sharing files via NFS:
(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.)
/tftpboot -mapall=nobody -ro 123.11.22.33where 123.11.22.33 is the IP address of the machine running the emulator process, as seen from the outside world.
# portmap # nfsd -u <--- u for UDP # mountd -n
# mount -o ro,-r=1024,-w=1024,-U,-3 my.server.com:/tftpboot /mnt or # mount my.server.com:/tftpboot /mntIf 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 outgoing 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.
(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:
/* * 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, 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; }
struct foo_data { int irq_nr; /* ... */ }
#define FOO_TICKSHIFT 14 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); }
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; }
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.
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.
To be compatible with pre-20040702 devices, a return value of 0 is treated by the caller (in src/memory_rw.c) as a value of -1.