| Message ID | 20240423221521.2923759-2-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: Collect host state snapshots into a struct | expand |
On Wednesday, April 24, 2024 6:15 AM, Sean Christopherson wrote: > @@ -403,7 +403,7 @@ static void vmx_update_fb_clear_dis(struct kvm_vcpu > *vcpu, struct vcpu_vmx *vmx) > * and VM-Exit. > */ > vmx->disable_fb_clear > = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && > - (host_arch_capabilities & > ARCH_CAP_FB_CLEAR_CTRL) && > + (kvm_host.arch_capabilities & > ARCH_CAP_FB_CLEAR_CTRL) && The line of code appears to be lengthy. It would be preferable to limit it to under 80 columns per line. > !boot_cpu_has_bug(X86_BUG_MDS) && > !boot_cpu_has_bug(X86_BUG_TAA); > > @@ -1116,12 +1116,12 @@ static bool update_transition_efer(struct > vcpu_vmx *vmx) > * atomically, since it's faster than switching it manually. > */ > if (cpu_has_load_ia32_efer() || > - (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) { > + (enable_ept && ((vmx->vcpu.arch.efer ^ kvm_host.efer) & EFER_NX))) > +{ > if (!(guest_efer & EFER_LMA)) > guest_efer &= ~EFER_LME; > - if (guest_efer != host_efer) > + if (guest_efer != kvm_host.efer) > add_atomic_switch_msr(vmx, MSR_EFER, > - guest_efer, host_efer, false); > + guest_efer, kvm_host.efer, false); > else > clear_atomic_switch_msr(vmx, MSR_EFER); > return false; > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index > d80a4c6b5a38..e69fff7d1f21 100644 > --- a/arch/x86/kvm/x86.h > +++ b/arch/x86/kvm/x86.h > @@ -33,6 +33,13 @@ struct kvm_caps { > u64 supported_perf_cap; > }; > > +struct kvm_host_values { > + u64 efer; > + u64 xcr0; > + u64 xss; > + u64 arch_capabilities; > +}; > + > void kvm_spurious_fault(void); > > #define KVM_NESTED_VMENTER_CONSISTENCY_CHECK(consistency_check) > \ > @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, > gpa_t cr2_or_gpa, > int emulation_type, void *insn, int insn_len); > fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); > > -extern u64 host_xcr0; > -extern u64 host_xss; > -extern u64 host_arch_capabilities; > - > extern struct kvm_caps kvm_caps; > +extern struct kvm_host_values kvm_host; Have you considered merging the kvm_host_values and kvm_caps into one unified structure? (If the concern is about naming, we could brainstorm a more encompassing term for them)
On Thu, Apr 25, 2024, Wei W Wang wrote: > On Wednesday, April 24, 2024 6:15 AM, Sean Christopherson wrote: > > @@ -403,7 +403,7 @@ static void vmx_update_fb_clear_dis(struct kvm_vcpu > > *vcpu, struct vcpu_vmx *vmx) > > * and VM-Exit. > > */ > > vmx->disable_fb_clear > > = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && > > - (host_arch_capabilities & > > ARCH_CAP_FB_CLEAR_CTRL) && > > + (kvm_host.arch_capabilities & > > ARCH_CAP_FB_CLEAR_CTRL) && > > The line of code appears to be lengthy. It would be preferable to limit it to under > 80 columns per line. I agree that staying under 80 is generally preferred, but I find this vmx->disable_fb_clear = (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); much more readable than this vmx->disable_fb_clear = (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); We should shorten the name to arch_caps, but I don't think that's a net positive, e.g. unless we do a bulk rename, it'd diverge from several other functions/variables, and IMO it would be less obvious that the field holds MSR_IA32_ARCH_CAPABILITIES. > > !boot_cpu_has_bug(X86_BUG_MDS) && > > !boot_cpu_has_bug(X86_BUG_TAA); > > > > @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, > > gpa_t cr2_or_gpa, > > int emulation_type, void *insn, int insn_len); > > fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); > > > > -extern u64 host_xcr0; > > -extern u64 host_xss; > > -extern u64 host_arch_capabilities; > > - > > extern struct kvm_caps kvm_caps; > > +extern struct kvm_host_values kvm_host; > > Have you considered merging the kvm_host_values and kvm_caps into one unified > structure? No really. I don't see any benefit, only the downside of having to come up with a name that is intuitive when reading code related to both. > (If the concern is about naming, we could brainstorm a more encompassing term > for them)
On Thursday, April 25, 2024 10:10 PM, Sean Christopherson wrote: > On Thu, Apr 25, 2024, Wei W Wang wrote: > > On Wednesday, April 24, 2024 6:15 AM, Sean Christopherson wrote: > > > @@ -403,7 +403,7 @@ static void vmx_update_fb_clear_dis(struct > > > kvm_vcpu *vcpu, struct vcpu_vmx *vmx) > > > * and VM-Exit. > > > */ > > > vmx->disable_fb_clear > > > = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && > > > - (host_arch_capabilities & > > > ARCH_CAP_FB_CLEAR_CTRL) && > > > + (kvm_host.arch_capabilities & > > > ARCH_CAP_FB_CLEAR_CTRL) && > > > > The line of code appears to be lengthy. It would be preferable to > > limit it to under > > 80 columns per line. > > I agree that staying under 80 is generally preferred, but I find this > > vmx->disable_fb_clear = (kvm_host.arch_capabilities & > ARCH_CAP_FB_CLEAR_CTRL) && > !boot_cpu_has_bug(X86_BUG_MDS) && > !boot_cpu_has_bug(X86_BUG_TAA); > > much more readable than this > > vmx->disable_fb_clear = (kvm_host.arch_capabilities & > ARCH_CAP_FB_CLEAR_CTRL) && > !boot_cpu_has_bug(X86_BUG_MDS) && > !boot_cpu_has_bug(X86_BUG_TAA); > > We should shorten the name to arch_caps, but I don't think that's a net > positive, e.g. unless we do a bulk rename, it'd diverge from several other > functions/variables, and IMO it would be less obvious that the field holds > MSR_IA32_ARCH_CAPABILITIES. Yeah, the above isn't nice and no need to do bulk rename. We could just shorten it here, e.g.: diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 4ed8c73f88e4..8d0ab5a6a515 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -393,6 +393,9 @@ static __always_inline void vmx_enable_fb_clear(struct vcpu_vmx *vmx) static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx *vmx) { + u64 arch_cap = kvm_host.arch_capabilities; + /* * Disable VERW's behavior of clearing CPU buffers for the guest if the * CPU isn't affected by MDS/TAA, and the host hasn't forcefully enabled @@ -402,7 +405,7 @@ static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx *vmx) * and VM-Exit. */ vmx->disable_fb_clear = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && - (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && + (arch_cap & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); > > > > !boot_cpu_has_bug(X86_BUG_MDS) && > > > !boot_cpu_has_bug(X86_BUG_TAA); > > > > > > > @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu > > > *vcpu, gpa_t cr2_or_gpa, > > > int emulation_type, void *insn, int insn_len); > fastpath_t > > > handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); > > > > > > -extern u64 host_xcr0; > > > -extern u64 host_xss; > > > -extern u64 host_arch_capabilities; > > > - > > > extern struct kvm_caps kvm_caps; > > > +extern struct kvm_host_values kvm_host; > > > > Have you considered merging the kvm_host_values and kvm_caps into one > > unified structure? > > No really. I don't see any benefit, only the downside of having to come up > with a name that is intuitive when reading code related to both. I thought the two structures perform quite similar jobs and most of the fields in kvm_cap, e.g. has_tsc_control, supported_perf_cap, could also be interpreted as host values?
On Thu, Apr 25, 2024, Wei W Wang wrote: > On Thursday, April 25, 2024 10:10 PM, Sean Christopherson wrote: > > We should shorten the name to arch_caps, but I don't think that's a net > > positive, e.g. unless we do a bulk rename, it'd diverge from several other > > functions/variables, and IMO it would be less obvious that the field holds > > MSR_IA32_ARCH_CAPABILITIES. > > Yeah, the above isn't nice and no need to do bulk rename. > We could just shorten it here, e.g.: Works for me. > > > > @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu > > > > *vcpu, gpa_t cr2_or_gpa, > > > > int emulation_type, void *insn, int insn_len); > > fastpath_t > > > > handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); > > > > > > > > -extern u64 host_xcr0; > > > > -extern u64 host_xss; > > > > -extern u64 host_arch_capabilities; > > > > - > > > > extern struct kvm_caps kvm_caps; > > > > +extern struct kvm_host_values kvm_host; > > > > > > Have you considered merging the kvm_host_values and kvm_caps into one > > > unified structure? > > > > No really. I don't see any benefit, only the downside of having to come up > > with a name that is intuitive when reading code related to both. > > I thought the two structures perform quite similar jobs and most of the fields in > kvm_cap, e.g. has_tsc_control, supported_perf_cap, could also be interpreted > as host values? No, kvm_caps is filtered and/or generated information, e.g. supported_perf_cap and supported_xss incorporate host/hardware support, but they also incorporate KVM's own capabilities. kvm_host holds pure, unadultered host values. XSS is a perfect example. If we shoved the host value in kvm_caps, then we'd have kvm_caps.supported_xss and kvm_caps.xss, which would be incredibly confusing. So then we'd need to rename it to kvm_caps.host_xss, which is also confusing, just less so, and also results in a longer name with no added value.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 1d13e3cd1dc5..8d3940a59894 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1846,7 +1846,6 @@ struct kvm_arch_async_pf { }; extern u32 __read_mostly kvm_nr_uret_msrs; -extern u64 __read_mostly host_efer; extern bool __read_mostly allow_smaller_maxphyaddr; extern bool __read_mostly enable_apicv; extern struct kvm_x86_ops kvm_x86_ops; diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 598d78b4107f..71f1518f0ca1 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3251,7 +3251,7 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_are */ hostsa->xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); hostsa->pkru = read_pkru(); - hostsa->xss = host_xss; + hostsa->xss = kvm_host.xss; /* * If DebugSwap is enabled, debug registers are loaded but NOT saved by diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index d5b832126e34..a896df59eaad 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -2422,7 +2422,7 @@ static void prepare_vmcs02_early(struct vcpu_vmx *vmx, struct loaded_vmcs *vmcs0 if (cpu_has_load_ia32_efer()) { if (guest_efer & EFER_LMA) exec_control |= VM_ENTRY_IA32E_MODE; - if (guest_efer != host_efer) + if (guest_efer != kvm_host.efer) exec_control |= VM_ENTRY_LOAD_IA32_EFER; } vm_entry_controls_set(vmx, exec_control); @@ -2435,7 +2435,7 @@ static void prepare_vmcs02_early(struct vcpu_vmx *vmx, struct loaded_vmcs *vmcs0 * bits may be modified by vmx_set_efer() in prepare_vmcs02(). */ exec_control = __vm_exit_controls_get(vmcs01); - if (cpu_has_load_ia32_efer() && guest_efer != host_efer) + if (cpu_has_load_ia32_efer() && guest_efer != kvm_host.efer) exec_control |= VM_EXIT_LOAD_IA32_EFER; else exec_control &= ~VM_EXIT_LOAD_IA32_EFER; @@ -4662,7 +4662,7 @@ static inline u64 nested_vmx_get_vmcs01_guest_efer(struct vcpu_vmx *vmx) return vmcs_read64(GUEST_IA32_EFER); if (cpu_has_load_ia32_efer()) - return host_efer; + return kvm_host.efer; for (i = 0; i < vmx->msr_autoload.guest.nr; ++i) { if (vmx->msr_autoload.guest.val[i].index == MSR_EFER) @@ -4673,7 +4673,7 @@ static inline u64 nested_vmx_get_vmcs01_guest_efer(struct vcpu_vmx *vmx) if (efer_msr) return efer_msr->data; - return host_efer; + return kvm_host.efer; } static void nested_vmx_restore_host_state(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index f10b5f8f364b..cb1bd9aebac4 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -258,7 +258,7 @@ static int vmx_setup_l1d_flush(enum vmx_l1d_flush_state l1tf) return 0; } - if (host_arch_capabilities & ARCH_CAP_SKIP_VMENTRY_L1DFLUSH) { + if (kvm_host.arch_capabilities & ARCH_CAP_SKIP_VMENTRY_L1DFLUSH) { l1tf_vmx_mitigation = VMENTER_L1D_FLUSH_NOT_REQUIRED; return 0; } @@ -403,7 +403,7 @@ static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx *vmx) * and VM-Exit. */ vmx->disable_fb_clear = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && - (host_arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && + (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); @@ -1116,12 +1116,12 @@ static bool update_transition_efer(struct vcpu_vmx *vmx) * atomically, since it's faster than switching it manually. */ if (cpu_has_load_ia32_efer() || - (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) { + (enable_ept && ((vmx->vcpu.arch.efer ^ kvm_host.efer) & EFER_NX))) { if (!(guest_efer & EFER_LMA)) guest_efer &= ~EFER_LME; - if (guest_efer != host_efer) + if (guest_efer != kvm_host.efer) add_atomic_switch_msr(vmx, MSR_EFER, - guest_efer, host_efer, false); + guest_efer, kvm_host.efer, false); else clear_atomic_switch_msr(vmx, MSR_EFER); return false; @@ -1134,7 +1134,7 @@ static bool update_transition_efer(struct vcpu_vmx *vmx) clear_atomic_switch_msr(vmx, MSR_EFER); guest_efer &= ~ignore_bits; - guest_efer |= host_efer & ignore_bits; + guest_efer |= kvm_host.efer & ignore_bits; vmx->guest_uret_msrs[i].data = guest_efer; vmx->guest_uret_msrs[i].mask = ~ignore_bits; @@ -4346,7 +4346,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx) } if (cpu_has_load_ia32_efer()) - vmcs_write64(HOST_IA32_EFER, host_efer); + vmcs_write64(HOST_IA32_EFER, kvm_host.efer); } void set_cr4_guest_host_mask(struct vcpu_vmx *vmx) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e9ef1fa4b90b..1b664385461d 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -98,6 +98,9 @@ struct kvm_caps kvm_caps __read_mostly = { }; EXPORT_SYMBOL_GPL(kvm_caps); +struct kvm_host_values kvm_host __read_mostly; +EXPORT_SYMBOL_GPL(kvm_host); + #define ERR_PTR_USR(e) ((void __user *)ERR_PTR(e)) #define emul_to_vcpu(ctxt) \ @@ -227,21 +230,12 @@ static struct kvm_user_return_msrs __percpu *user_return_msrs; | XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \ | XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE) -u64 __read_mostly host_efer; -EXPORT_SYMBOL_GPL(host_efer); - bool __read_mostly allow_smaller_maxphyaddr = 0; EXPORT_SYMBOL_GPL(allow_smaller_maxphyaddr); bool __read_mostly enable_apicv = true; EXPORT_SYMBOL_GPL(enable_apicv); -u64 __read_mostly host_xss; -EXPORT_SYMBOL_GPL(host_xss); - -u64 __read_mostly host_arch_capabilities; -EXPORT_SYMBOL_GPL(host_arch_capabilities); - const struct _kvm_stats_desc kvm_vm_stats_desc[] = { KVM_GENERIC_VM_STATS(), STATS_DESC_COUNTER(VM, mmu_shadow_zapped), @@ -315,8 +309,6 @@ const struct kvm_stats_header kvm_vcpu_stats_header = { sizeof(kvm_vcpu_stats_desc), }; -u64 __read_mostly host_xcr0; - static struct kmem_cache *x86_emulator_cache; /* @@ -1023,11 +1015,11 @@ void kvm_load_guest_xsave_state(struct kvm_vcpu *vcpu) if (kvm_is_cr4_bit_set(vcpu, X86_CR4_OSXSAVE)) { - if (vcpu->arch.xcr0 != host_xcr0) + if (vcpu->arch.xcr0 != kvm_host.xcr0) xsetbv(XCR_XFEATURE_ENABLED_MASK, vcpu->arch.xcr0); if (guest_can_use(vcpu, X86_FEATURE_XSAVES) && - vcpu->arch.ia32_xss != host_xss) + vcpu->arch.ia32_xss != kvm_host.xss) wrmsrl(MSR_IA32_XSS, vcpu->arch.ia32_xss); } @@ -1054,12 +1046,12 @@ void kvm_load_host_xsave_state(struct kvm_vcpu *vcpu) if (kvm_is_cr4_bit_set(vcpu, X86_CR4_OSXSAVE)) { - if (vcpu->arch.xcr0 != host_xcr0) - xsetbv(XCR_XFEATURE_ENABLED_MASK, host_xcr0); + if (vcpu->arch.xcr0 != kvm_host.xcr0) + xsetbv(XCR_XFEATURE_ENABLED_MASK, kvm_host.xcr0); if (guest_can_use(vcpu, X86_FEATURE_XSAVES) && - vcpu->arch.ia32_xss != host_xss) - wrmsrl(MSR_IA32_XSS, host_xss); + vcpu->arch.ia32_xss != kvm_host.xss) + wrmsrl(MSR_IA32_XSS, kvm_host.xss); } } @@ -1626,7 +1618,7 @@ static bool kvm_is_immutable_feature_msr(u32 msr) static u64 kvm_get_arch_capabilities(void) { - u64 data = host_arch_capabilities & KVM_SUPPORTED_ARCH_CAP; + u64 data = kvm_host.arch_capabilities & KVM_SUPPORTED_ARCH_CAP; /* * If nx_huge_pages is enabled, KVM's shadow paging will ensure that @@ -9777,19 +9769,19 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) goto out_free_percpu; if (boot_cpu_has(X86_FEATURE_XSAVE)) { - host_xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); - kvm_caps.supported_xcr0 = host_xcr0 & KVM_SUPPORTED_XCR0; + kvm_host.xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); + kvm_caps.supported_xcr0 = kvm_host.xcr0 & KVM_SUPPORTED_XCR0; } - rdmsrl_safe(MSR_EFER, &host_efer); + rdmsrl_safe(MSR_EFER, &kvm_host.efer); if (boot_cpu_has(X86_FEATURE_XSAVES)) - rdmsrl(MSR_IA32_XSS, host_xss); + rdmsrl(MSR_IA32_XSS, kvm_host.xss); kvm_init_pmu_capability(ops->pmu_ops); if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) - rdmsrl(MSR_IA32_ARCH_CAPABILITIES, host_arch_capabilities); + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities); r = ops->hardware_setup(); if (r != 0) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index d80a4c6b5a38..e69fff7d1f21 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -33,6 +33,13 @@ struct kvm_caps { u64 supported_perf_cap; }; +struct kvm_host_values { + u64 efer; + u64 xcr0; + u64 xss; + u64 arch_capabilities; +}; + void kvm_spurious_fault(void); #define KVM_NESTED_VMENTER_CONSISTENCY_CHECK(consistency_check) \ @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, int emulation_type, void *insn, int insn_len); fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); -extern u64 host_xcr0; -extern u64 host_xss; -extern u64 host_arch_capabilities; - extern struct kvm_caps kvm_caps; +extern struct kvm_host_values kvm_host; extern bool enable_pmu;
Add "struct kvm_host_values kvm_host" to hold the various host values that KVM snapshots during initialization. Bundling the host values into a single struct simplifies adding new MSRs and other features with host state/values that KVM cares about, and provides a one-stop shop. E.g. adding a new value requires one line, whereas tracking each value individual often requires three: declaration, definition, and export. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/svm/sev.c | 2 +- arch/x86/kvm/vmx/nested.c | 8 +++---- arch/x86/kvm/vmx/vmx.c | 14 ++++++------ arch/x86/kvm/x86.c | 38 +++++++++++++-------------------- arch/x86/kvm/x86.h | 12 +++++++---- 6 files changed, 35 insertions(+), 40 deletions(-)