Will We Have Qemu (x86 System Emulation On Arm)?

[urjaman]

So i took a look at the status page at CODE
http://bellard.org/qemu/status.html
and it says that ARM CPU as host is 'Testing' ("Note: Testing means that the emulator is working on most of the regression tests, but that some important application fail.")

Because i really don't have any ARM devices around (my nokia 6630 doesn't really cut it for this ),
and cant easily test it, does anyone know whether it will work? (eg. has anyone tested it).
If someone with a beagleboard or a pandora devkit is willing to test it, i would really like to know the results.

And then the other question, how slow(/fast?...) the emulator would be on the pandora (@600Mhz)?
My feeling is that it would be something from 16mhz 386 to 66mhz 486.

And then the reason why I'm asking...
[Maybe a bit offtopic, but to point that this could be really used for something]
I have an old (1995) (shareware) game that ran on win3.1/win95/winNT called Stars! (1.0),
Only requirements mentioned are 8MB RAM, 640x480 256 colors display (recommended 800x600).
It runs perfectly on wine. It does run even on dosbox+win3.1 but 640x480 16-colours doesn't make me happy.
So i put together a small linux (based on ArchLinux) that had just the things needed to build wine (and X) and built wine on it,
then removed most things not needed for running X and Wine (got it down to 132MB (not compressed)), put it on a compressed .qcow image and i have a 50MB linux that can run Stars
The X.org cirrus driver can be coersed into running the qemu window at 800x480 by adding a modeline for it.
And so running qemu fullscreen would give native resolution on the pandora, this was one of the musts for me.
And since the Stars window can be resized to any size, i think this qemu+linux+wine would run Stars! on the pandora at native resolution (with 24-bit colors) pretty well
I actually think that the problem wont be how well Stars will run, but how long it will take for the linux to boot, so i've optimized the boot time a lot.
Now it boots on a C2D P8400 running (single core) _at 800 mhz without any qemu accelerators_ to X and shows the Stars! menu in 35 seconds.

 

[sindbad]

It may be a good idea to try the approach of the Darwine team, arm wine + userspace emulation in qemu, since no hardware gets emulated.

 

[bzar]

Wow. You really want to play that game on the pandora, don't you ?

 

[ldesnogu]

Qemu on ARM has indeed received very little testing. If I find some time, I will give it a test on my Beagle (but don't hold your breath, I am very busy).

Sindbad proposal looks good since you proved that Wine can correctly run Stars! (BTW, this is a game I've always wanted to try, but I never found a way to buy a legitimate copy). It would also remove the need to have a copy of Windows, and would be faster since user emulation is faster. OTOH Darwine looks dead to me...

 

[urjaman]

I was thinking of trying the Qemu userspace emulation, but there's some problem with the qemu that i got off the archlinux repos, or some other incompatibility and just decided to emulate the full system (i could take the libs and wine that i have on that full system and emulate just that on the userspace, if it worked), but here's the problem:
CODE
urjaman ~/linux-2.6.28.5 $ qemu-i386 -L / /bin/sh
sh-3.2$ ls
sh: fork: Invalid argument
sh-3.2$


fork() doesn't work... thats bad, though /bin/ls works (but nags):
CODE
urjaman ~/linux-2.6.28.5 $ qemu-i386 -L / /bin/ls
qemu: Unsupported syscall: 240
COPYING Module.symvers crypto ipc samples vmlinux
CREDITS README drivers kernel scripts vmlinux.o
Documentation REPORTING-BUGS firmware lib security
Kbuild System.map fs mm sound
MAINTAINERS arch include modules.order usr
Makefile block init net virt


and then i thought that a good test would be to run qemu (system emulation) on top of qemu-i386 (userspace emulation:
CODE
urjaman ~ $ qemu-i386 -L / /usr/bin/qemu -m 32 starstux_rw.qcow
qemu: Unsupported syscall: 240
qemu: Unsupported syscall: 259
timer_create: Function not implemented
Dynamic Ticks disabled
Unsupported ioctl: cmd=0x4004700c
Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
qemu: Unsupported syscall: 240
qemu: Unsupported syscall: 240
Unsupported ipc call: 24 (version 0)
qemu: Unsupported syscall: 240
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
Segmentation fault


The window pop's up, then closes.
and of course i can try to do what i came to do (emulate wine+Stars), but:
CODE
urjaman ~ $ qemu-i386 -L / /usr/bin/wine DBC/STARS/STARS_.EXE
qemu: Unsupported syscall: 240
wine: glibc >= 2.3 without NPTL or TLS is not a supported combination.
It will most likely crash. Please upgrade to a glibc with NPTL support.
Segmentation fault


It would be nice if it worked...

 

[sindbad]

Sindbad proposal looks good since you proved that Wine can correctly run Stars! (BTW, this is a game I've always wanted to try, but I never found a way to buy a legitimate copy). It would also remove the need to have a copy of Windows, and would be faster since user emulation is faster. OTOH Darwine looks dead to me...

I think his idea was to run a small linux distro with wine which in turn runs Stars!, not a copy of windows.

The darwine project is dead because it is no longer needed (x86 in macs), but their technique should work.

 

[urjaman]

Sindbad proposal looks good since you proved that Wine can correctly run Stars! (BTW, this is a game I've always wanted to try, but I never found a way to buy a legitimate copy). It would also remove the need to have a copy of Windows, and would be faster since user emulation is faster. OTOH Darwine looks dead to me...

The Stars! 1.0 i have used to be a freely distributable shareware version (i'll see if i can dig up that original), before i got interested in its inner workings and hmm, slightly modified the binary. (I don't think that it's legal to even modify it, but since it's propably very abandonware (no one is interested) I'm not worried about modifying it for my personal use, but i'm not going to distribute any modified versions, just to be safe)

EDIT: CODE
http://www.megaupload.com/?d=XD56DXOR

It's a tar.gz of the original files distributed. Sorry for having to resort to megaupload.

 

[Pickle]

What about bochs? we know that will work it runs on the gp2x.
Also dosbox + win 3.1 i believe setup correctly with the right emulated svga card can run in 256 colors

 

[ldesnogu]

What about bochs? we know that will work it runs on the gp2x.
Also dosbox + win 3.1 i believe setup correctly with the right emulated svga card can run in 256 colors

Don't both require a copy of Windows ?

 

[Pickle]

What about bochs? we know that will work it runs on the gp2x.
Also dosbox + win 3.1 i believe setup correctly with the right emulated svga card can run in 256 colors

Don't both require a copy of Windows ?

ah i see he wants to run x86 linux with wine to emulate windows. Bochs I think could do that, dosbox no, you would need a copy of windows.

 

[Eolair]

Stars! is still one of the best space strategy games out there. Awesome job if you can get it working on Pandora!

CODE
http://en.wikipedia.org/wiki/Stars!

 

[sindbad]

What about bochs? we know that will work it runs on the gp2x.
Bochs implements every single CPU instruction in C++. That does indeed make it very portable and it will run on the pandora out of the box, but it also makes it tons slower than qemu. Nice for experiments and showing off, but not very practical.

 

[Ze_ro]

And then the other question, how slow(/fast?...) the emulator would be on the pandora (@600Mhz)?
My feeling is that it would be something from 16mhz 386 to 66mhz 486.

I'd be very impressed if you could get as high as a 16MHz 386.

--Zero

 

[Exophase]

This approach is very potentially advantageous, much more so than it would be for DOS (where the same basic approach is taken by DOSBox). This is because Windows apps are typically much more heavily abstracted than DOS apps are.

Windows provides a nice simple flat memory address space which is easy to translate to a Linux address space w/o any emulation done whatsoever for the memory layer. That removes a huge bottleneck jammed in CPU emulation that DOSBox must deal with (even emulating an 8086 physical memory space and allowing traps to I/O would be much more costly).

Windows apps also do more code in drivers and kernel resources than DOS ones do, typically much more because the actual services DOS provided eventually got pretty slow and obsolete compared to rolling your own. Since this would be handled natively in Linux equivalents with some wrapper code inbetween it could also be much more efficient.

With a VERY good recompiler you could possibly do much better than 66MHz 486. With qemu, which is a bit limited by its approach, I do not really know what you could do. But 33MHz+ 486 is probably very doable.

 

[ldesnogu]

If that is any indication, I could push ARM qemu on x86 to about 5 cycles per simulated instruction (for a SPEC2k benchmark, so something bigger than the stupid nbench but with good reuse of generated code).

I wonder what you find limited in qemu approach? IIRC you once wrote dedicating a register to a guest register was a big win. This can be done in qemu. Do you have something else in mind?

 

[Exophase]

You can't do register allocation or any real multiple instruction analysis at all. This is a pretty big loss for a load-store arch like ARM. It's pretty naive in general for anyone to think that a "portable" recompiler copying around chunks of C code can come close to a fine tuned one.

5 cycles on what ARM? If it's Cortex-A8 then that's not really that good.

 

[arrrgh]

Qemu or Bochs running on the Pandora would be great, even at slow 386 speeds just for messing around in DOS. DOSBox is good for games but Bochs and Qemu have much more complete emulation and just being able to tinker around in a full installation of DOS(or maybe Windows 3.1) would be awesome!

 

[Esn]

This approach is very potentially advantageous, much more so than it would be for DOS (where the same basic approach is taken by DOSBox). This is because Windows apps are typically much more heavily abstracted than DOS apps are.

Windows provides a nice simple flat memory address space which is easy to translate to a Linux address space w/o any emulation done whatsoever for the memory layer. That removes a huge bottleneck jammed in CPU emulation that DOSBox must deal with (even emulating an 8086 physical memory space and allowing traps to I/O would be much more costly).

Windows apps also do more code in drivers and kernel resources than DOS ones do, typically much more because the actual services DOS provided eventually got pretty slow and obsolete compared to rolling your own. Since this would be handled natively in Linux equivalents with some wrapper code inbetween it could also be much more efficient.

With a VERY good recompiler you could possibly do much better than 66MHz 486. With qemu, which is a bit limited by its approach, I do not really know what you could do. But 33MHz+ 486 is probably very doable.

Very interesting post. Forgive me for asking, but does this mean that games from the mid-1990s that required EITHER DOS or Windows 95 could in fact be possible to run at a good speed, as long as the "Windows 95" version is used? Here is one example:

CODE
http://en.wikipedia.org/wiki/Star_Control_3

 

[Exophase]

Very interesting post. Forgive me for asking, but does this mean that games from the mid-1990s that required EITHER DOS or Windows 95 could in fact be possible to run at a good speed, as long as the "Windows 95" version is used? Here is one example:

CODE
http://en.wikipedia.org/wiki/Star_Control_3

Depends on many factors, but it's at least possible.

 

[atomicthumbs]

-snip-