linux-kernel - Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest and host

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <933dc95ead067cf1b362f7b8c3ce9a72e31658d2.camel@infradead.org>
Date: Thu, 21 Aug 2025 18:37:45 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner
 <tglx@...utronix.de>,  Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,  x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org,  graf@...zon.de, Ajay
 Kaher <ajay.kaher@...adcom.com>, Alexey Makhalov
 <alexey.makhalov@...adcom.com>, Colin Percival <cperciva@...snap.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On Thu, 2025-08-21 at 09:26 -0700, Sean Christopherson wrote:
> On Sat, Aug 16, 2025, David Woodhouse wrote:
> > In https://lkml.org/lkml/2008/10/1/246 VMware proposed a generic standard
> > for harmonising CPUID between hypervisors. It was mostly shot down in
> > flames, but the generic timing leaf at 0x4000_0010 didn't quite die.
> > 
> > Mostly the hypervisor leaves at 0x4000_0xxx are very hypervisor-specific,
> > but XNU and FreeBSD as guests will look for 0x4000_0010 unconditionally,
> > under any hypervisor. The EC2 Nitro hypervisor has also exposed TSC
> > frequency information in this leaf, since 2020.
> > 
> > As things stand, KVM guests have to reverse-calculate the TSC frequency
> > from the mul/shift information given to them in the KVM clock to convert
> > ticks into nanoseconds, with a corresponding loss of precision.
> 
> I would rather have the VMM use the Intel-define CPUID.0x15 to enumerate the
> TSC frequency. 

The problem with that is that it's been quite unreliable. The kernel
doesn't trust it even on chips as recent (hah) as Skylake. I'd be
happier to trust what the hypervisor explicitly gives us. But yes, it
should be *one* of the sources of information before we reverse-
calculate it from the pvclock. 

>  I would also love, love, love reviews on that series.
> 
> https://lore.kernel.org/all/20250227021855.3257188-36-seanjc@google.com

The carousel has come back round to me frowning at clocks, and
hopefully I can spend some time looking over that, and bringing in some
of the other fixes I had which are still needed, quite soon... 

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)