On Mon, May 24, 2021 at 2:44 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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 saying these can't be passhthrough, but there needs to be strong > justification for letting the guest read/write them directly. If we virtualize XFD, we have to context switch the guest/host values on VM-entry/VM-exit, don't we? If we don't, we're forced to synthesize the #NM on any instruction that would access a disabled state component, and I don't think we have any way of doing that. We could intercept a guest WRMSR to these MSRs, but it sounds like the guest can still implicitly write to IA32_XFD_ERR, if we allow it to have a non-zero IA32_XFD. Perhaps the answer is "don't virtualize XFD."
