On 5/24/21 2:43 PM, Sean Christopherson wrote: > On Sun, Feb 07, 2021, Jing Liu wrote: >> Passthrough both MSRs to let guest access and write without vmexit. > Why? Except for read-only MSRs, e.g. MSR_CORE_C1_RES, passthrough MSRs are > costly to support because KVM must context switch the MSR (which, by the by, is > completely missing from the patch). > > In other words, if these MSRs are full RW passthrough, guests with XFD enabled > will need to load the guest value on entry, save the guest value on exit, and > load the host value on exit. That's in the neighborhood of a 40% increase in > latency for a single VM-Enter/VM-Exit roundtrip (~1500 cycles => >2000 cycles). I'm not taking a position as to whether these _should_ be passthrough or not. But, if they are, I don't think you strictly need to do the RDMSR/WRMSR at VM-Exit time. Just like the "FPU", XFD isn't be used in normal kernel code. This is why we can be lazy about FPU state with TIF_NEED_FPU_LOAD. I _suspect_ that some XFD manipulation can be at least deferred to the same place where the FPU state is manipulated: places like switch_fpu_return() or kernel_fpu_begin(). Doing that would at least help the fast VM-Exit/VM-Enter paths that really like TIF_NEED_FPU_LOAD today. I guess the nasty part is that you actually need to stash the old XFD MSR value in the vcpu structure and that's not available at context-switch time. So, maybe this would only allow deferring the WRMSR. That's better than nothing I guess.
