On 6/27/21 7:00 PM, Liu, Jing2 wrote:A bit of flag can be found so far though the space is somehow nervous. What I
On 6/24/2021 1:50 AM, Dave Hansen wrote:Why is this a concern? You're worried about finding a single bit worth
On 5/24/21 2:43 PM, Sean Christopherson wrote:Hi Dave,
On Sun, Feb 07, 2021, Jing Liu wrote:I'm not taking a position as to whether these _should_ be passthrough or
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).
not. But, if they are, I don't think you strictly need to do the
RDMSR/WRMSR at VM-Exit time.
Thanks for reviewing the patches.
When vmexit, clearing XFD (because KVM thinks guest has requested AMX) can
be deferred to the time when host does XSAVES, but this means need a new
flag in common "fpu" structure or a common macro per thread which works
only dedicated for KVM case, and check the flag in 1) switch_fpu_prepare()
2) kernel_fpu_begin() . This is the concern to me.
of space somewhere?