LWN.net Logo

QEMU 1.0 released

QEMU 1.0 released

Posted Dec 4, 2011 2:43 UTC (Sun) by MegabytePhreak (subscriber, #60945)
In reply to: QEMU 1.0 released by SEJeff
Parent article: QEMU 1.0 released

QEMU is actually more capable than most other virtualization tools for this, since it supports user more emulation. That is can emulate the code inside a binary (Such as GCC)compiled for ARM Linux (for example), on an x86 system. It also emulates the ARM syscall interface, translating the syscalls on the fly into syscalls on the host system. This would include loading the (ARM) shared libraries for the emulated processes.

In many ways it is like WINE, except for the fact there is emulation involved of course. I suppose it may even be possible to use the binfmt feature to detect the architecture of the elf files and run the non-native ones in QEMU automatically, just like is done with Wine (and Mono, etc.).


(Log in to post comments)

QEMU 1.0 released

Posted Dec 4, 2011 4:16 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

Sure it's possible. Here are instructions for doing the whole process manually. Note that unless the ARM bits are in a chroot, life is very complicated, if not impossible:

http://tinkering-is-fun.blogspot.com/2009/12/running-arm-...

On Debian, at least, the package qemu-user-static already installs that binfmt stuff for you.

debootstrap --arch armel --foreign suite path/to/new/chroot
cp /usr/bin/qemu-arm-static path/to/new/chroot/usr/bin/
chroot path/to/new/chroot /deboostrap/deboostrap --second-stage

The qemu package provides a helper script to wrap those commands:

qemu-debootstrap

Unlike wine, though, performance is not close to native. Well, it may emulate closely the performance of some specific ARM devices. Recall QEMU has to do much more emulation than WINE. But having it on your native system, with your "unlimited" disk space is helpful as well.

QEMU 1.0 released

Posted Dec 4, 2011 4:40 UTC (Sun) by MegabytePhreak (subscriber, #60945) [Link]

Interesting. I'm guessing the complicated part about a non-chroot approach is mostly to do with shared library paths? Since this has to be handled anyway for i386-on-x64 under the new apt/deb multiarch support, is there any chance that eventually it could simply be a matter of installing a gcc:armel package?

QEMU 1.0 released

Posted Dec 4, 2011 11:49 UTC (Sun) by Jonno (subscriber, #49613) [Link]

That is the general idea of Debian multiarch, and it already works, though not in the default configuration.

All you need to do is install a multi-arch enabled dpkg (default on Ubuntu 11.10, on Debian you still need to build from source), add the line "foreign-architecture armel" to /etc/dpkg/dpkg.cfg.d/multiarch, and install libgcc1:armel, libc6:armel, libstdc++6:armel, as well as any other shared libraries used by the application(s) you want to run (as well as qemu-user-static for your host architecture ofcourse).

QEMU 1.0 released

Posted Dec 5, 2011 11:56 UTC (Mon) by drag (subscriber, #31333) [Link]

Debian has some very clever stuff for doing cross-platform development.

Combine that with Qemu's ability and Debian blows away 99% of the vendor provided platform SDKs that I have ran into.

Not that I am a expert on the subject.

QEMU 1.0 released

Posted Dec 4, 2011 22:07 UTC (Sun) by foom (subscriber, #14868) [Link]

Yes, that is in fact the plan with the new debian multiarch stuff, so far as I understand it. One of the reasons why proper multiarch is much nicer than the hacky "lib64" directory.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds