From patchwork Thu Aug 9 09:48:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 176038 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id B42672C009E for ; Thu, 9 Aug 2012 19:49:08 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SzPMQ-0002XV-Tw; Thu, 09 Aug 2012 09:48:58 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SzPMO-0002Wu-1p for kernel-team@lists.ubuntu.com; Thu, 09 Aug 2012 09:48:56 +0000 Received: from p5b2e349a.dip.t-dialin.net ([91.46.52.154] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SzPMN-0007wq-SW for kernel-team@lists.ubuntu.com; Thu, 09 Aug 2012 09:48:56 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: [Precise SRU] Fix nexted load of kvm-intel Date: Thu, 9 Aug 2012 11:48:54 +0200 Message-Id: <1344505734-16005-1-git-send-email-stefan.bader@canonical.com> X-Mailer: git-send-email 1.7.9.5 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com Since adding the RDPMC feature in kernels after 3.3, a guest running a v3.3+ kernel on a host running 3.2 cannot load the kvm-intel module (Intel CPU obviously). The reason is a check made on module load time for that feature being present in the MSRs passed to the guest. Upstreams reasoning is that no real CPU ever had this flag so they do not want to change the check in newer kernels (while kvm-amd is not so tight). So from the patch that added support for RDPMC based exiting, only the bit that adds the feature to the nested MSR is taken. I tested this and could load the module, bring up a nested guest and also ran "perf test" which on newer versions does a RDPMC test that fails gracefully enough to seem ok (syscall returns error). This was proposed for stable and I just saw the emails being sent but since it has some impact on Quantal testing I want to make sure this gets in as soon as possible. -Stefan From b79a5f03b4d9a1a56949d6ef38fd4879ff1b8aee Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Thu, 10 Nov 2011 14:57:25 +0200 Subject: [PATCH] UBUNTU: (pre-stable) KVM: VMX: Set CPU_BASED_RDPMC_EXITING for nested Based on commit fee84b079d5ddee2247b5c1f53162c330c622902 upstream. Intercept RDPMC and forward it to the PMU emulation code. Newer vmx support will only allow to load the kvm_intel module if RDPMC_EXITING is supported. Even without the actual support this part of the change is required on 3.2 hosts. BugLink: http://bugs.launchpad.net/bugs/1031090 Signed-off-by: Stefan Bader Acked-by: Andy Whitcroft --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 114fe29..94e6749 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1957,6 +1957,7 @@ static __init void nested_vmx_setup_ctls_msrs(void) #endif CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING | CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING | + CPU_BASED_RDPMC_EXITING | CPU_BASED_ACTIVATE_SECONDARY_CONTROLS; /* * We can allow some features even when not supported by the