There are currently some inefficiencies in how we virtualize the fpu and cr0: - we trap changes to cr0.ts unconditionally; however, when the guest fpu is loaded, we're not really interested in cr0.ts (it's only needed when the host fpu is loaded, to prevent the guest from accessing it) - we deactivate the fpu on every guest context switch, for no reason at all Fix these issues by being as lazy as possible: deactivate the fpu at heavyweight context switch time, and when the fpu is active, give the guest ownership of cr0.ts. Joerg, I wasn't able to extend this to svm/npt. If we switch to the guest with the host fpu loaded, then we must set cr0.ts and enable cr0 intercepts. I think this is much more expensive than keeping the guest fpu active at all times. Avi Kivity (5): KVM: VMX: trace clts and lmsw instructions as cr accesses KVM: Replace read accesses of vcpu->arch.cr0 by an accessor KVM: VMX: Allow the guest to own some cr0 bits KVM: Lazify fpu activation and deactivation KVM: VMX: Give the guest ownership of cr0.ts when the fpu is active arch/x86/include/asm/kvm_host.h | 3 ++ arch/x86/kvm/emulate.c | 6 ++-- arch/x86/kvm/kvm_cache_regs.h | 12 +++++++++ arch/x86/kvm/mmu.c | 2 +- arch/x86/kvm/mmu.h | 2 +- arch/x86/kvm/svm.c | 46 ++++++++++++++++++++++-------------- arch/x86/kvm/vmx.c | 48 ++++++++++++++++++++++++-------------- arch/x86/kvm/x86.c | 26 ++++++++++++--------- 8 files changed, 93 insertions(+), 52 deletions(-) -- 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
