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.
