From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Sent: Thursday, July 14, 2022 8:03 AM > > Maxim Levitsky <mlevitsk@xxxxxxxxxx> writes: > > > On Wed, 2022-07-13 at 17:05 +0200, Vitaly Kuznetsov wrote: > >> Normally, genuine Hyper-V doesn't expose architectural invariant TSC > >> (CPUID.80000007H:EDX[8]) to its guests by default. A special PV MSR > >> (HV_X64_MSR_TSC_INVARIANT_CONTROL, 0x40000118) and corresponding CPUID > >> feature bit (CPUID.0x40000003.EAX[15]) were introduced. When bit 0 of the > >> PV MSR is set, invariant TSC bit starts to show up in CPUID. When the > >> feature is exposed to Hyper-V guests, reenlightenment becomes unneeded. > > > > If I understood the feature correctly from the code, it allows the HyperV, or in this > > case KVM acting as HyperV, to avoid unconditionally exposing the invltsc bit > > in CPUID, but rather let the guest know that it can opt-in into this, > > by giving the guest another CPUID bit to indicate this ability > > and a MSR which the guest uses to opt-in. > > > > Are there known use cases of this, are there guests which won't opt-in? > > > > Linux prior to dce7cd62754b and some older Windows guests I guess. FWIW, the idea is to avoid having this new functionality magically show up in existing guests when the Hyper-V host is upgraded. A guest OS version with the code to opt-in has presumably been tested to make sure it works correctly when the functionality is exposed. > > >> > >> Note: strictly speaking, KVM doesn't have to have the feature as exposing > >> raw invariant TSC bit (CPUID.80000007H:EDX[8]) also seems to work for > >> modern Windows versions. The feature is, however, tiny and straitforward > >> and gives additional flexibility so why not. > > > > This means that KVM can also just unconditionally expose the invtsc bit > > to the guest, and the guest still uses it. > > Yes, this feature doesn't bring much by itself (at least with modern > Windows versions). I've implemented it while debugging what ended up > being https://lore.kernel.org/kvm/20220712135009.952805-1-vkuznets@xxxxxxxxxx/ > (so the issue wasn't enlightenments related after all) but as I think it > may come handy some day so why keeping it in my private stash. > > > > > Nitpick: It might be worth it to document it a bit better somewhere, > > as I tried to do in this mail. > > TLFS sounds like the right place for it but ... it's not there... oh well. > I've sent a nag email to the Hyper-V folks about updating the TLFS. Michael
