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-next>] [day] [month] [year] [list]
Message-ID: <20250814120237.2469583-1-dwmw2@infradead.org>
Date: Thu, 14 Aug 2025 12:56:02 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>,
	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>,
	Alok N Kataria <akataria@...are.com>
Subject: [PATCH 0/3] Support "generic" CPUID timing leaf as KVM guest and host.


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 0x40000010 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.

There's certainly no way we can sanely use 0x4000_0010 for anything *else*
at this point. Just adopt it, as both guest and host. We already have the
infrastructure for keeping the TSC frequency information up to date for
the Xen CPUID leaf anyway, so do precisely the same for this one.

David Woodhouse (3):
      KVM: x86: Restore caching of KVM CPUID base
      KVM: x86: Provide TSC frequency in "generic" timing infomation CPUID leaf
      x86/kvm: Obtain TSC frequency from CPUID if present

 arch/x86/include/asm/kvm_host.h      |  1 +
 arch/x86/include/asm/kvm_para.h      |  1 +
 arch/x86/include/uapi/asm/kvm_para.h | 11 +++++++++++
 arch/x86/kernel/kvm.c                | 10 ++++++++++
 arch/x86/kernel/kvmclock.c           |  7 ++++++-
 arch/x86/kvm/cpuid.c                 | 23 ++++++++++++++++++-----
 6 files changed, 47 insertions(+), 6 deletions(-)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ