public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: kvm <kvm@vger.kernel.org>
Subject: [ANNOUNCE] kvm-kmod-2.6.32.12 & kvm-kmod-2.6.33.3
Date: Tue, 27 Apr 2010 11:09:25 +0200	[thread overview]
Message-ID: <4BD6A9C5.7020308@siemens.com> (raw)

Two updates to the stable kvm-kmod series have just been released.
kvm-kmod-2.6.33.3 is the "normal" one as it reflects the most recent
stable kernel. Here is the corresponding changelog:

KVM changes since kvm-kmod-2.6.33.1:
 - Fix TSS size check for 16-bit tasks
 - Increase NR_IOBUS_DEVS limit to 200
 - fix the handling of dirty bitmaps to avoid overflows
 - fix kvm_mmu_zap_page() and its calling path
 - VMX: Save/restore rflags.vm correctly in real mode
 - allow bit 10 to be cleared in MSR_IA32_MC4_CTL
 - Don't spam kernel log when injecting exceptions due to bad cr writes
 - SVM: Fix memory leaks that happen when svm_create_vcpu() fails
 - VMX: Update instruction length on intercepted BP
 - Add KVM_CAP_X86_ROBUST_SINGLESTEP

kvm-kmod changes:
 - stop distributing generated kvm-kmod-config.h


But I also cooked up a new 2.6.32-based kvm-kmod. This happened for two
reasons. One is that we are maintaining a kvm-kmod-2.6.32 internally
anyway, and the other is that there are currently a few fixes in 2.6.32
that do not exist in 2.6.33 (at least one is already confirmed to be
ported to the latter soon as well). So here is the changelog for
kvm-kmod-2.6.32.12:

KVM changes since kvm-kmod-2.6.32.9:
 - Fix TSS size check for 16-bit tasks
 - Increase NR_IOBUS_DEVS limit to 200
 - fix the handling of dirty bitmaps to avoid overflows
 - fix kvm_mmu_zap_page() and its calling path
 - VMX: Save/restore rflags.vm correctly in real mode
 - allow bit 10 to be cleared in MSR_IA32_MC4_CTL
 - Don't spam kernel log when injecting exceptions due to bad cr writes
 - SVM: Fix memory leaks that happen when svm_create_vcpu() fails
 - disable paravirt mmu reporting
 - VMX: Disable unrestricted guest when EPT disabled
 - SVM: Reset cr0 properly on vcpu reset
 - VMX: Use macros instead of hex value on cr0 initialization
 - VMX: Update instruction length on intercepted BP
 - Fix segment descriptor loading
 - x86 emulator: Fix popf emulation
 - x86 emulator: Check IOPL level during io instruction emulation
 - x86 emulator: fix memory access during x86 emulation
 - x86 emulator: Add Virtual-8086 mode of emulation
 - x86 emulator: Check CPL level during privilege instruction emulation
 - x86 emulator: Add group9 instruction decoding
 - x86 emulator: Forbid modifying CS segment register by mov instruction
 - x86 emulator: Add group8 instruction decoding

kvm-kmod changes:
 - stop distributing generated kvm-kmod-config.h
 - Avoid bash patterns during install and sync-hdr
 - Do not wrap cpufreq_get for 2.6.32


The roadmap for future kvm-kmod packages currently looks like this: The
2.6.33 series will be replaced by a 2.6.34 one once the latter kernel is
released. kvm-kmod-2.6.32 will be continued for some time, specifically
as long as the effort is that low. Please drop me a note if that series
is more than a nice-to-have for someone (as it might be run as a stable
package along with an even older kernel)!

Jan

                 reply	other threads:[~2010-04-27  9:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BD6A9C5.7020308@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox