QEMU and performance testing

[bbramble]

Whilst waiting for hardware, I thought I'd bite the bullet and set up a QEMU environment to play in, test some code compilation for arm-specific errors and general performance issues. The environment I am playing with is as follows:

Host PC:

Core 2 Duo @ 1.8GHz (no VT)

2GB RAM

Fedora 15

Virtual Environment:

debian-17-02-2012.img

zImage_3.1.9

TAP networking

[bbramble]

The network environment was established as follows:

Create /etc/qemu-ifup as follows:

Change IF to your ethernet device (eth0 for most people), and ETH0IP, GATEWAY and BROADCAST as necessary for your environment

#!/bin/sh
#
# script to bring up the tun device in QEMU in bridged mode
# first parameter is name of tap device (e.g. tap0)
#
# some constants specific to the local host - change to suit your host
IF=p2p1
#
ETH0IP=192.168.1.175
GATEWAY=192.168.1.2
BROADCAST=192.168.1.255
#
# First take eth0 down, then bring it up with IP 0.0.0.0
#
/sbin/ifdown ${IF}
/sbin/ifconfig ${IF} 0.0.0.0 promisc up
#
# Bring up the tap device (name specified as first argument, by QEMU)
#
/usr/sbin/openvpn --mktun --dev $1 --user `id -un`
/sbin/ifconfig $1 0.0.0.0 promisc up
#
# create the bridge between eth0 and the tap device
#
/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 ${IF}
/usr/sbin/brctl addif br0 $1
#
# only a single bridge so loops are not possible, turn off spanning tree protocol
#
/usr/sbin/brctl stp br0 off
#
# Bring up the bridge with ETH0IP and add the default route
#
/sbin/ifconfig br0 $ETH0IP netmask 255.255.255.0 broadcast $BROADCAST
/sbin/route add default gw $GATEWAY
#
# stop firewall - comment this out if you don't use Firestarter
#
/sbin/service firestarter stop

Create /etc/qemu-ifdown as follows, changing IF again

#!/bin/sh
#
# Script to bring down and delete bridge br0 when QEMU exits
#
IF=p2p1
IF#=eth0
# Bring down eth0 and br0
#
/sbin/ifdown ${IF}
/sbin/ifdown br0
/sbin/ifconfig br0 down
#
# Delete the bridge
#
/usr/sbin/brctl delbr br0
#
# bring up eth0 in "normal" mode
#
/sbin/ifconfig ${IF} -promisc
/sbin/ifup ${IF}
#
# delete the tap device
#
/usr/sbin/openvpn --rmtun --dev $1
#
# start firewall again
#
/sbin/service firestarter start

[bbramble]

The environment is then started with (from the directory with debian6-17-02-2012.img  and  zImage_3.1.9 in):

Start the TAP device for networking:

sudo /etc/qemu-ifup tap0

Start QEMU:

sudo qemu-system-arm -M versatilepb -cpu arm1136-r2 -hda debian6-17-02-2012.img -kernel zImage_3.1.9 -m 192 -append "root=/dev/sda2" -net nic -net tap,ifname=tap0,script=no

If you are on a DHCP network, the virtual arm machine should get an IP address. You can log into with the username "pi" and password "suse". If all is working OK you should be able to ping the outside world, use apt-get etc and generally play around.

[bbramble]

Once the environment is up and running, I copied some legacy code (originally written for DOS 20 years ago, ported to the original Archimedes ARM environment, ported again to Linux about 10 years ago). Having installed the relevant libraries etc. everything compiled OK on the emulated box. GDB worked as expected and I managed to clear up a minor networking issue. As a dev environment, if you are used to command line and limited memory, everything works acceptably.

As I had ssh access, and the x libs seemed to be installed (xeyes, always a good test), I thought I'd install a few graphical packages and play with them. xchat ran fine, so I moved onto openoffice.org - I needed to clean out the apt cache as I ran out of space in the rootfs, but after that it installed and oowriter ran fine. Memory usage was high as would be expected (35% when idle, 40% with a 4MB conveted Word .doc file). Abiword did better resource-wise (17% with the doc loaded) but makes more of a mess of the formatting.

Now, this is an emulated environment, so CPU speed and IO bandwidth likely will have nothing in common with the actual hardware, and I was running X remotely not on the virtual Pi, but from a limited memory perspective fairly heavyweight packages do run, and run acceptably in an emulator.

[augusto.beiro]

Mmm.

I'm assumming you're using cnxsoft kernel. there's one issue here. If you boot into your guest system, cat /proc/cpuinfo will show no vfp support. (at least this happened to me).

As R-Pi has one nice fpu, and i'm preparing my debian packages to use it, I couldn't test any recompiled app (Illegal instruction error).

So. recompiled 3.0.4 kernel patched with this  http://thoronir.net/raspi-dev/linux-arm.patch (This patch enables armv6 on versatile platform) and enabled fpu support on config.

So if you're using qemu 1.0 and an enabled fpu kernel suporting arm1176-jfs, you could test fpu .

Another options is use coremu.  coremu is a modified qemu with smp support (each guest cpu is running on his own thread on host). You will have to get a cortex enabled kernel (ubuntu has some). Sometimes cross compiling is a hell, so ii's usefull to compile some  native-tied packages. But it's still slow, but faster than single qemu.

[bbramble]

augusto.beiro said:


Mmm.

I'm assumming you're using cnxsoft kernel. there's one issue here. If you boot into your guest system, cat /proc/cpuinfo will show no vfp support. (at least this happened to me).

As R-Pi has one nice fpu, and i'm preparing my debian packages to use it, I couldn't test any recompiled app (Illegal instruction error).



Yup, correct. The code I am using is (should be?) unaffected by the FPU as it is all integer only, and likewise the applications run so far should not be affected. However, my main purpose was to run tests within the constrained memory rather than to do any testing of CPU etc. as the emulated environment makes any statements on that spurious at best.