[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#626003: pu: package qemu-kvm/0.12.5+dfsg-5+squeeze2

Hash: SHA1

Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: pu
Severity: normal


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

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

 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:

 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:

  * 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

  * 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:
 Upstream commit:

 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!

Version: GnuPG v1.4.10 (GNU/Linux)


Reply to: