On Wed, Sep 21, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@xxxxxxxxxx> 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);
