linux-kernel - RE: [PATCH 0/3] KVM: x86: Hyper-V invariant TSC control feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <PH0PR21MB3025BBC14E4BB4F2435B542FD78C9@PH0PR21MB3025.namprd21.prod.outlook.com>
Date:   Mon, 18 Jul 2022 15:07:30 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     vkuznets <vkuznets@...hat.com>,
        Maxim Levitsky <mlevitsk@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC:     Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: RE: [PATCH 0/3] KVM: x86: Hyper-V invariant TSC control feature

From: Vitaly Kuznetsov <vkuznets@...hat.com> Sent: Thursday, July 14, 2022 8:03 AM
> 
> Maxim Levitsky <mlevitsk@...hat.com> 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@redhat.com/ 
> (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