RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

[Liu, Jing2]

On 10/14/2021 11:01 PM, Paolo Bonzini wrote:
[...]
> Calls into the function, but doesn't necessarily allocate anything.
> What you wrote below looks correct to me, thanks.
> 

For the guest dynamic state support, based on the latest discussion,
four copies of XFD need be cared and switched, I'd like to list as follows.

- vcpu->arch.xfd: this is the real guest value for running.
Since kernel init XFD before XCR0, so I think KVM can initialize it as
bit[n]=0, for a guest start value. Otherwise, kvm_arch_vcpu_create()
need initializes vcpu->arch.xfd=guest_fpu->xfd=user_fpu->xfd=1.
Guest wrmsr XFD trap will make it update.

- user_fpu->fpstate->xfd: Qemu itself and not for guest, which is
probably always set.

- guest_fpu->fpstate->xfd: this is for KVM internal value between time[*].
KVM reinitializes it as bit[n]=0 (not the same as user_fpu), and it will be
updated when guest wrmsr trap. Thus, before passthrough, it's the same
as vcpu->arch.xfd, thus vmenter/vmexit need not rewrite msr.
After passthrough, this keeps bit[n] as 0 forever.

- current_fpu->fpstate->xfd: it should be the same as KVM internal value
between time[*].
[*] this means between kvm_load_guest_fpu and kvm_put_guest_fpu.

From guest booting timeline,  the values are: 

Booting start...   # In this time, vcpu->arch.xfd[n]=guest_fpu->xfd[n]=0
Init XFD by WRMSR(XFD[n], 1)  	# Then, vcpu->arch.xfd[n]=guest_fpu->xfd[n]=1
Init XCR0 by XSETBV 	
...
#NM WRMSR(XFD[n], 0)  # Then, guest_fpu->xfd[n]=0, vcpu->arch.xfd[n]=0.
vcpu->arch.xfd will be updated in later vmexits. 

BTW, we only need lazy-passthrough XFD WRITE and passthrough
READ directly.

Thanks,
Jing

> Paolo
> 
> > Also you really should not wait until _all_ dynamic states are cleared
> > in guest XFD.  Because a guest which has bit 18 and 19 available but
> > only > uses one of them is going to trap on every other context switch due
> to XFD writes.