Messages in this thread | | | Date | Wed, 21 Sep 2022 14:32:44 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCH v3 3/6] KVM: x86: Hyper-V invariant TSC control |
| |
On Wed, Sep 21, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@google.com> writes: > > It's still not obvious to me why KVM shouldn't do: > > > > if (!hv_vcpu) > > return false; > > > > return !(hv_vcpu->cpuid_cache.features_eax & HV_ACCESS_TSC_INVARIANT) || > > !(to_kvm_hv(vcpu->kvm)->hv_invtsc_control & HV_INVARIANT_TSC_EXPOSED); > > > > I.e. why is invariant TSC _not_ suppressed on Hyper-V by default? > > In case we switch to suppressing invtsc (CPUID.80000007H:EDX[8]) by > default, i.e. when HV_ACCESS_TSC_INVARIANT was not set in guest visible > CPUIDs, this is going to be a behavioral change for the already existing > configurations and we certainly don't want that. It was expirementally > proven that at least some Windows versions are perfectly happy when they > see invtsc without this PV feature so I don't see a need to break the > status quo. > > this is VMM's job, not KVM's.
Gotcha. Can you add a comment to capture this? In particular, the part about it being KVM's responsibility iff the Hyper-V control is exposed to the guest.
Hmm, and I think it makes to repackage the code so that the "is KVM responsible" check is separated from the "is the control enabled". E.g.
/* * If Hyper-V's invariant TSC control is exposed to the guest, KVM is * responsible for suppressing the invariant TSC CPUID flag if the * Hyper-V control is not enabled. */ if (!hv_vcpu || !(hv_vcpu->cpuid_cache.features_eax & HV_ACCESS_TSC_INVARIANT)) return false;
return !(to_kvm_hv(vcpu->kvm)->hv_invtsc_control & HV_INVARIANT_TSC_EXPOSED);
| |