> > Is it better to use guest_cpuid_has_mpx() instead of > vmx_mpx_supported()? > > CPUID hasn't been set yet, so I think it is okay to key it on > vmx_mpx_supported(). It will be deactivated soon afterwards. > > Or even do it unconditionally; just make sure to add a comment about it. > > >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index > >> 5f38188..5993f5f > >> 100644 > >> --- a/arch/x86/kvm/x86.c > >> +++ b/arch/x86/kvm/x86.c > >> @@ -7060,7 +7060,8 @@ void kvm_put_guest_fpu(struct kvm_vcpu > *vcpu) > >> fpu_save_init(&vcpu->arch.guest_fpu); > >> __kernel_fpu_end(); > >> ++vcpu->stat.fpu_reload; > >> - kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu); > >> + if (!kvm_x86_ops->mpx_supported()) > >> + kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu); > >> trace_kvm_fpu(0); > >> } > > This is a hotter path. Here it's definitely better to avoid the call to > kvm_x86_ops->mpx_supported(). Especially because, with MPX enabled, > you would call this on every userspace exit. > > Yang's suggestion of using CPUID is actually more valuable here. You could > add a new field eager_fpu in kvm->arch and update it in kvm_update_cpuid. Thanks for your comments. I will change the code according to your suggestion. > Thanks, > > Paolo -- 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