Bug#626003: pu: package qemu-kvm/0.12.5+dfsg-5+squeeze2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: pu
Severity: normal
Hello.
I'd like to upload a new bugfix release of package qemu-kvm
to squeeze. The new release contains fixes of several bugs
which were found since the squeeze is out, from which there
are several important bugs. Here's the changelog for the
new release:
qemu-kvm (0.12.5+dfsg-5+squeeze2) stable; urgency=low
* cirrus_vga:fix-division-by-0-for-color-expansion-rop-92d675d1c1.diff
(fix from upstream) - fixes division by zero with some guests
like WinNT 4.0 and WinME.
* fix-vnc-zlib-overflow.diff (backport from 0.14) (closes: #616159)
* qdev-dont-hw_error-in-qdev_init_nofail-bd6c9a61.diff -
don't abort but exit on user errors (closes: #619452)
* fix transitional kvm package description (closes: #625206)
* fix long-standing migration bug on 32bits (closes: #625571)
-- Michael Tokarev <mjt@tls.msk.ru> Sat, 07 May 2011 21:18:15 +0400
qemu-kvm is a full virtualization package for x86 hardware, it provides
a "virtual hardware" (a VM) which can be used to install other operating
systems.
Here's a short summary/description of each change in the proposed release.
* cirrus_vga:fix-division-by-0-for-color-expansion-rop-92d675d1c1.diff
(fix from upstream) - fixes division by zero with some guests
like WinNT 4.0 and WinME.
This fixes a crash (SIGFPE, division by zero) under certain conditions
(most notable when using old operating systems like winNT 4.0 as the
guest) when using cirrus logic virtual video card. There's no bug filed
against qemu-kvm package for this. The fix is a patch that went into
later upstream version of the package, taken as-is, it can be found at
http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=commit;h=e20556178fc5b49f300cd1619b1d7ccbe1ad0220
Unfortunately the fix does not let these old guests to run in qemu-kvm
still, due to other issues which were fixed upstream but the patch is
more intrusive thant is allowable for stable. For the curious it can be
found here:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=0d14905b5eb8aa1c2e195e13478bb7c74e1776db
But at least the fix I picked up stops the crash, and the crash can be
triggered under other conditions too (it's not a security problem, there
are lots of places in qemu where it just exits/aborts on bad guest behavour).
* fix-vnc-zlib-overflow.diff (backport from 0.14) (closes: #616159)
This fixes an important bug, -- crash of qemu-kvm after >2Gb of data is
transferred over VNC connection. The fix is backported from upstream,
it has been applied to 0.14.1 -stable version. The fix is pretty trivial
and obvious:
http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=commit;h=cbac2ce887ec34c3485ba036b44682dbd303c08d
* qdev-dont-hw_error-in-qdev_init_nofail-bd6c9a61.diff -
don't abort but exit on user errors (closes: #619452)
This is a small bugfix, -- when using wrong options in command line,
current version calls abort() with scary backtrace, instead of just
printing an error and exiting more or less quietly.
* fix transitional kvm package description (closes: #625206)
This is another minor bugfix, an error in "kvm" transitional package
description.
* fix long-standing migration bug on 32bits (closes: #625571)
This is a fix for a serious functionality issue. Basically, in qemu-kvm
as shipped in squeeze, on 32bit host, guest migration does not work at
all, kvm process crashes (memory corruption) right when attempting
migration. Note that in qemu-kvm, migration is used not only to
migrate a guest from one host to another, but also to save guest state
and resume the guest later. This is the most important bugfix in whole
series, in my opinion anyway, and most possible problematic one too,
because the fix is quite difficult to understand. The commit:
http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=commit;h=697e5cce08c68ead85340928c183f841a040e829
Upstream commit:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=51b0c6065aa6e47a47094d73e24be298a4a7f3a1
Since 0.12, many changes went to upstream code in that area, and
this bug transfrmed several times during upstream work past 0.12,
half of that has been fixed some time ago, the other half very
recently. All that code allocates a chunk of memory for kernel
data based on some length which may be anything. Kernel keeps
that data in memory which size is rounded to the next machine
word (32 or 64 bits), for optimization. The problem happens
when userspace allocates buffer of exact length for the data,
but the kernel when copies more bytes to it (up to 3 bytes more)
due to that rounding. Both kernel and userspace next use only
exact number of bytes, so it does not matter how many extra
space is allocated, the important part is to keep the rounding
when communicating with kernel. Sure thing it's a bad kernel
interface design, but we have to work around this.
The backported change ensures that the buffer allocated is
always large enough (rounding to 64bits instead of size of long),
so that works even for 32bit userspace running on 64bit kernel
(this is the second half of the fix, which makes migration work
on mixed 32/64 bits environment), and changes one place where
the rounding has been forgotten entirely (this is the first half
of the fix, which makes 32bit migration possible).
The analysis of the original upstream problem, second half of
the fix, and the backport to 0.12 were done my me.
The whole package has been tested on several different host
environments (pure 32 bits, pure 64bits, mixed 32/64 bits)
with several different guests (several versions and distributions
of linux, windows XP, windows 7 32 and 64 bits, windows NT 4.0)
with several different configurations, to ensure there are no
regressions. I tried to hit the problematic areas as hard as
possible, so now I'm fairy confident the new release works as
expected. It's a good idea to have it for the next squeeze
point release (6.0.2).
Thank you for your attention!
/mjt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iJwEAQECAAYFAk3FjKQACgkQUlPFrXTwyDgvHgP9F+3LixIy2uvpYS+8P01N2e1o
gBpVgCRYLBsVN1SRa6k0hj/cRjiCSwkvVaUHB6E91N9vhrPmoiNmcVitlr3pbGw5
9+Vu88m8dSwucikEgqM9hzinGQVBUYurKOrYy1gTKLyHIUJrlXVN5gZoNWR/DDn/
MJIj8sOg0LVQbiUuPH4=
=2DNO
-----END PGP SIGNATURE-----
Reply to: