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