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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
