QEMU 1.0 released

[Posted December 2, 2011 by corbet]

From:		Anthony Liguori <aliguori-AT-us.ibm.com>
To:		qemu-devel <qemu-devel-AT-nongnu.org>
Subject:		[ANNOUNCE] QEMU 1.0 release
Date:		Thu, 01 Dec 2011 15:23:37 -0600
Message-ID:		<4ED7F059.8040408@us.ibm.com>
Archive‑link:		Article

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of
QEMU 1.0!

Over 8 years ago, Fabrice Bellard started QEMU as a small tool to run x86 Linux 
binaries on non-x86 Linux platforms.  QEMU has since evolved into a cross 
architecture full system simulator capable of simulating 14 different target 
architectures across a wide variety of host platforms.  QEMU can simulate over 
400 different hardware devices in dozens of different boards.

QEMU also forms the heart of multiple hardware virtualization platforms 
including Xen and KVM.

Over those 8 years, we have seen almost 20,000 changesets from close to 400 
unique authors.  I'd like to personally thank everyone who has contributed to 
making this release and all of our previous releases a success!

In this release, we have seen many improvements.  For the a full summary of 
changes, see the ChangeLog below.  You can download 1.0 from qemu.org at:

http://wiki.qemu.org/download/qemu-1.0.tar.gz

ChangeLog:

== General ==
* i386-softmmu is no longer named ''qemu'' but instead referred to as 
''qemu-system-i386'' for better consistency with other targets.  A new tool is 
likely to be introduced that uses the ''qemu'' name so distributions are advised 
to not undo this change.
* QEMU now uses a separate thread for VCPU execution.  This merges the biggest 
difference between the qemu-kvm tree and upstream QEMU.
* A new memory dispatch API has been added internally.  A new monitor command 
"info mtree" can show the hierarchy of memory regions in the guest.
* QEMU now has a build dependency on glib and makes extensive use of glib.
* QEMU now can run on more hosts. Hosts without a native code generator can use 
the TCG interpreter (TCI). See [[Features/TCI]] for more information.

== Block devices (disks) ==
* QEMU now supports I/O latency accounting in the monitor command "info blockstats".
* Errors are now tracked per device and are shown by the monitor command "info 
block".
* All image formats now support asynchronous operation.  IDE and SCSI emulation 
will use this feature, while other devices (notably floppy and SD) will not.

=== IDE/ATAPI ===
* A large number of bugs were fixed regarding CD media change and tray locking.

=== SCSI ===
* Memory management errors could crash QEMU when scsi-disk encountered I/O 
errors.  Many instances of this problem were fixed.
* The accuracy of error handling for SCSI emulation has been greatly improved.
* SCSI devices can now be addressed by channel, target (id) and LUN.  Not all 
emulated HBAs will support this feature (in particular, the LSI controller will 
not).
* Block device pass through is now supported through a new scsi-block device. 
The scsi-block device works with block devices (like /dev/sda or /dev/sr0) 
rather than /dev/sgN devices, and is more efficient because it does not consume 
arbitrary amounts of memory when the guest does large data transfers.
* SCSI CD-ROMs now report media changed events.
* SCSI CD-ROMs now support DVD images.
* Bugfixes for IDE media change also apply to SCSI.
* SCSI devices now report a unit attention condition when the system is started 
or reset.  This may cause problems with old firmware versions.

=== VDI ===
* Now supports discarded blocks in dynamically-sized images.

== User-mode networking (SLIRP) ==
* SLIRP can process ARP replies and gratuitous ARP requests from the guest.

== ARM ==
* QEMU now supports the new Cortex-A15 instructions in linux-user mode (via 
"-cpu any"): VFPv4 fused multiply-accumulate (VFMA, VFMS, VFNMA, VFNMS) and also 
integer division (UDIV, SDIV).
* The vexpress-a9, versatileab, versatilepb and realview-* boards now have audio 
support.
* QEMU is known not to work on ARM hosts in this release. (ARM target emulation 
is fine.)

=== pSeries ===
* sPAPR VIO devices can now be created with -device.

== Xtensa ==
* QEMU now supports DC232b and FSF xtensa CPU cores.
* QEMU now supports sim (similar to Tensilica ISS) and LX60/LX110/LX200 machines.

== Migration ==
* QEMU now supports live migration using image files like QCOW2 on shared storage

Regards,

Anthony Liguori

QEMU 1.0 released

Posted Dec 2, 2011 20:57 UTC (Fri) by vmpn (subscriber, #55435) [Link] (22 responses)

Wonder if this finally allows memory model > 1Gb

QEMU 1.0 released

Posted Dec 2, 2011 21:06 UTC (Fri) by aliguori (subscriber, #30636) [Link] (21 responses)

On 64-bit, we support 1TB and higher. On 32-bit, we are limited to the userspace address space.

QEMU 1.0 released

Posted Dec 2, 2011 21:36 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

And this is, of course, not in any way new in QEMU 1.0!

QEMU 1.0 released

Posted Dec 3, 2011 21:24 UTC (Sat) by vmpn (subscriber, #55435) [Link] (1 responses)

When I tried emulating ARM system where the code resides @ 0x40000000 qemu 0.14 (I think) ended up with all zeros instead of the code. If I moved the code base to an earlier address it worked fine but did not reflect true device it was emulating

QEMU 1.0 released

Posted Dec 4, 2011 8:59 UTC (Sun) by bradh (guest, #2274) [Link]

Thats a bug in the emulation (i.e. you're not properly emulating the real hardware, or your real hardware doesn't support it).

On many ARM boards, there really is hardware limits on how large memory can be, so the emulated hardware will break just as the real hardware would.

Short version: don't -m 1024 and assume it works.

QEMU 1.0 released

Posted Dec 3, 2011 10:16 UTC (Sat) by mastro (guest, #72665) [Link] (17 responses)

IIRC qemu used to not offer an usable x86 emulation on any host that wasn't x86 itself, because calls to fork() failed. I think the LOCK prefix wasn't implemented.

Is this still the case?

QEMU 1.0 released

Posted Dec 3, 2011 13:33 UTC (Sat) by chithanh (guest, #52801) [Link] (16 responses)

Windows 98 has been running in QEMU on Loongson(MIPS) host since 2007. So at least somewhat usable.
http://www.lemote.com/bbs/viewthread.php?tid=5661

QEMU 1.0 released

Posted Dec 3, 2011 21:09 UTC (Sat) by landley (guest, #6789) [Link] (15 responses)

You're confusing application emulation and system emulation.

Application emulation runs a userspace program and intercepts system calls to fake access to the operating system. System emulation runs a kernel and intercepts hardware access to fake a motherboard.

If you booted windows 98 under it, it was system emulation. If it couldn't call fork(), it was application emulation.

Rob

QEMU 1.0 released

Posted Dec 4, 2011 1:16 UTC (Sun) by drag (guest, #31333) [Link] (14 responses)

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.

QEMU 1.0 released

Posted Dec 4, 2011 6:44 UTC (Sun) by ebirdie (guest, #512) [Link] (1 responses)

Could someone shed some light on this, what is the news here with version 1.0?

> == Migration ==
> * QEMU now supports live migration using image files like QCOW2 on shared storage

QEMU 1.0 released

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

Before 1.0, live migration was not supported if you were using qcow2 images (even with shared storage). The reason for this limitation was that qcow2 cached data which became stale during live migration. We now drop the caches which sounds simple and obvious but was fairly difficult to work out :-)

QEMU 1.0 released

Posted Dec 4, 2011 10:26 UTC (Sun) by geofft (subscriber, #59789) [Link] (1 responses)

What is likely to be the nature of the "qemu" tool?

I at least have shell scripts that depend on running "qemu" with certain arguments. If the "qemu" tool does some target architecture detection and supports all the arguments the qemu-system-* command does, then that's fine (and then distributions can provide a symlink or a tiny shell script until the tool appears). If not, this seems a little backwards-incompatible, so I'm curious what the benefit is.

(Strictly speaking, I think I only have shell scripts that depend on running "kvm" with certain arguments, but I imagine the situation is similar.)

QEMU 1.0 released

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

I have been kicking around a git style tool that acts as a front end to all of the target specific binaries.