On 08/16/2012 08:14 AM, Xudong Hao wrote:
> Enable KVM FPU fully eager restore, if there is other FPU state which isn't
> tracked by
> CR0.TS bit.
>
> Tested with these cases:
> 1) SpecCPU2000 workload( 1 VM, 2 VMs)
> 2) Program for floating point caculate
Is the motivation performance or correctness?
> +
> struct kvm_memory_alias {
> __u32 slot; /* this has a different namespace than memory slots */
> __u32 flags;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index b6379e5..2e628e5 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5966,7 +5966,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
> vcpu->guest_fpu_loaded = 0;
> fpu_save_init(&vcpu->arch.guest_fpu);
> ++vcpu->stat.fpu_reload;
> - kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
> + /*
> + * Currently KVM trigger FPU restore by #NM (via CR0.TS),
> + * till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
> + * by TS bit, there might be other FPU state is not tracked
> + * by TS bit.
Which state is that?
> Here it only make FPU deactivate request and do
> + * FPU lazy restore for these cases: 1)xsave isn't enabled
> + * in guest, 2)all guest FPU states can be tracked by TS bit.
> + * For others, doing fully FPU eager restore.
> + */
> + if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
> + !(vcpu->arch.xcr0 & ~KVM_XSTATE_LAZY))
> + kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
> trace_kvm_fpu(0);
> }
Is there no way to track accesses to this extended state?
Although I expect that on modern hardware which exits rarely, eager fpu
reload might be more performant.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
