Hi Paolo, > On 10/14/2021 7:39 PM, Paolo Bonzini wrote: > > On 14/10/21 13:30, Liu, Jing2 wrote: > > I guess we're worrying about is when KVM is sched_out, a nonzero > > XFD_ERR can be lost by other host thread. We can save guest XFD_ERR in > > sched_out and restore before next vmenter. Kernel is assumed not using > > AMX thus softirq won't make it lost. > > I think this solves the problem. So we can directly passthrough RW of > > it, and no need to rdmsr(XFD_ERR) in vmexit. > > Correct; you can also use the "user-return MSRs" machinery (until Linux > starts using AMX in the kernel, but that shouldn't happen too soon). > Thanks for the suggestion. For user-return MSR mechanism using by emulated MSRs, it calls kvm_set_user_return_msr() to wrmsr of guest value, update curr value and switch host once kernel exit to userspace. For XFD_ERR, it's automatically changed by H/W in guest, so KVM need correctly update guest XFD_ERR value at a time, which is different from other user-return MSRs, e.g., at KVM preemption and kvm_put_guest_fpu() time, and both cases need not do wrmsr. And for kvm_put_guest_fpu(), it does return to userspace. Also, XFD_ERR cannot refer to vmx->guest_uret_msrs_loaded to update before vmenter, since curr may not an up-to-date value. My feeling is the mechanism may not much suitable for this case and need special handling. Since guest non-zero XFD_ERR is rare case at vmexit, how about saving XFD_ERR when preemption, mark flag=true and restore if non-zero before vcpu enter? This seems simple and direct way, drawback is if XFD_ERR is not changed when schedule out, KVM need a wrmsr, but this only happens when it's non-zero&&flag=true. Thanks, Jing > Paolo