QEMU 1.0 released

Posted Dec 4, 2011 1:16 UTC (Sun) by drag (guest, #31333)
In reply to: QEMU 1.0 released by landley
Parent article: QEMU 1.0 released

Yes, I believe using Qemu it should be possible to setup a chroot environment for doing things like cross-platform compiling, running non-x86 applications on a x86 system, and such things...

QEMU 1.0 released

Posted Dec 4, 2011 2:10 UTC (Sun) by SEJeff (guest, #51588) [Link] (13 responses)

Just as possible as doing it through KVM, Xen, or VirtualBox. Qemu is an emulator, not at all comparable to something like wine.

QEMU 1.0 released

Posted Dec 4, 2011 2:25 UTC (Sun) by drag (guest, #31333) [Link] (6 responses)

Well seeing how KVM uses Qemu (I think Xen can use it also, haven't kept up with Xen stuff) I would certainly hope it is as capable as Qemu standalone.

I have used Qemu for some minimal cross-platform Linux development for ARM on Debian using my x86 laptop, but it was a while ago and I don't remember the details.

QEMU 1.0 released

Posted Dec 4, 2011 2:40 UTC (Sun) by SEJeff (guest, #51588) [Link] (5 responses)

KVM does not have to use Qemu[1]. Xen only uses bits of Qemu on hosts that lack the processor virtualization extensions such as SVM or VMX.

[1] https://lwn.net/Articles/447556/

QEMU 1.0 released

Posted Dec 4, 2011 14:34 UTC (Sun) by aliguori (subscriber, #30636) [Link]

Xen uses QEMU as the device model with any HVM guest.

QEMU 1.0 released

Posted Dec 4, 2011 20:05 UTC (Sun) by jnguyen (guest, #72727) [Link] (3 responses)

The relatively new KVM (native) is different from the KVM (based on Qemu) that most Linux users are familiar with, and I think the latter is the one that drag was referring to. I believe the native KVM was written from scratch and so has not much to do with the KVM based on Qemu.

And these are different again from the KVM (switch) that has been around for even longer. I do wish they picked different names.

QEMU 1.0 released

Posted Dec 4, 2011 20:56 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

And, of course, the KVM kernel component is used both by the new KVM tool and by qemu-kvm.

QEMU 1.0 released

Posted Dec 5, 2011 10:26 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

People are getting very nit picky.

Yeah sure you can use something other then Qemu with KVM, but the Qemu + KVM is what people are going to be generally using at this time.

QEMU 1.0 released

Posted Dec 5, 2011 12:16 UTC (Mon) by nix (subscriber, #2304) [Link]

Yes. What I was really nitpicking at was people who said that QEMU was used by KVM. As with any kernel service, it's the other way around!

QEMU 1.0 released

Posted Dec 4, 2011 2:43 UTC (Sun) by MegabytePhreak (guest, #60945) [Link] (5 responses)

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.).

QEMU 1.0 released

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

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 (guest, #60945) [Link] (3 responses)

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] (1 responses)

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 (guest, #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.