Re: Nested kvm_intel broken on pre 3.3 hosts

[Avi Kivity <avi@redhat.com>]

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