On 09/10/2012 06:29 AM, Hao, Xudong wrote:
>>
>> Doesn't help. We can have:
>>
>> host: deactivate fpu for some reason
>> guest: set cr4.osxsave, xcr0.bit3
>> host: enter guest with deactivated fpu
>> guest: touch fpu
>>
>> result: host fpu corrupted.
>
> Avi, I'm not sure if I fully understand of you. Do you mean enter guest with
> a fpu_active=0 and then fpu does not restore?
Yes.
> If so, I will add fpu_active=1 in the no-lazy case.
>
> - kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
> + if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) &&
> + (vcpu->arch.xcr0 & ~((u64)KVM_XSTATE_LAZY))) {
> + kvm_x86_ops->fpu_activate(vcpu);
> + vcpu->fpu_active=1;
> + }
> + else
> + kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
>
It doesn't help here.
1 guest boot
2 kvm_userspace_exit (deactivates fpu)
3 XSETBV exit that sets xcr0.new_bit
4 kvm_enter
There is no call to kvm_put_guest_fpu() between 3 and 4, you need
something in __kvm_set_xcr() to activate the fpu.
kvm_put_guest_fpu() doesn't need to activate the fpu then, just to avoid
deactivating it.
Note you also need to consider writes to xcr0 and cr4 that happen in the
reverse order due to live migration.
--
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
