From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested kvm_intel broken on pre 3.3 hosts Date: Thu, 02 Aug 2012 18:26:53 +0300 Message-ID: <501A9C3D.9080602@redhat.com> References: <5019471C.6050907@redhat.com> <1343920756-32362-1-git-send-email-stefan.bader@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nyh@math.technion.ac.il, Gleb Natapov , Andy Whitcroft , kvm@vger.kernel.org To: Stefan Bader Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45374 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752928Ab2HBP1C (ORCPT ); Thu, 2 Aug 2012 11:27:02 -0400 In-Reply-To: <1343920756-32362-1-git-send-email-stefan.bader@canonical.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2012 06:19 PM, Stefan Bader wrote: > I started to pick #7 (#6 is in to have things in-sync between > SVM and VMX). Most other patches then were needed as dependencies. > The only difference here is #2 which I found being applied together > with #1 (which is a dependency). Since #2 is rather change to add > support than to fix a bug it was applied only to our 3.2 tree. But > maybe this would be the time to get it into the upstream 3.2 stable > as well. I would leave the decision to you, just that the testing I > have done, was basically with that addition. The test was just an > installation of a nested guest (so not necessarily testing RDPMC, > only the fact that with that applied to 3.2, a 3.5 is able to load > the kvm-intel module). > > What I also did not do is to look much into the other direction, > like what patches may be important as that feature now would be > supported in 3.2. I think people on this list are likely in a much > better position to decide that. > > So here the series I used to compile and test on top of 3.2: > > 0001-KVM-Move-cpuid-code-to-new-file.patch > 0002-KVM-expose-latest-Intel-cpu-new-features-BMI1-BMI2-F.patch > 0003-KVM-Expose-kvm_lapic_local_deliver.patch > 0004-KVM-Expose-a-version-2-architectural-PMU-to-a-guests.patch > 0005-KVM-Add-generic-RDPMC-support.patch > 0006-KVM-SVM-Intercept-RDPMC.patch > 0007-KVM-VMX-Intercept-RDPMC.patch No, you're backporting the entire feature. All we need is to expose RDPMC intercept to the guest. It should be sufficient to backport the bits in nested_vmx_setup_ctls_msrs() and nested_vmx_exit_handled(). -- error compiling committee.c: too many arguments to function