[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4a3be390fe559de0bd5c61d24853d88f96a6ab6a.camel@infradead.org>
Date: Thu, 04 Sep 2025 14:14:57 +0200
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paul Durrant <pdurrant@...zon.co.uk>, Fred Griffoul
<fgriffo@...zon.co.uk>, Colin Percival <cperciva@...snap.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" <x86@...nel.org>, "H.
Peter Anvin" <hpa@...or.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Graf (AWS),
Alexander" <graf@...zon.de>, Ajay Kaher <ajay.kaher@...adcom.com>, Alexey
Makhalov <alexey.makhalov@...adcom.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
and host
On Thu, 2025-09-04 at 04:59 -0700, Sean Christopherson wrote:
>
> I thought the original problem being solved was that the _guest_ doesn't know the
> effective TSC frequency? Userspace can already get the effectively TSC frequency
> via KVM_GET_TSC_KHZ, why do we need another uAPI to provide that? (Honest question,
> I feel like I'm missing something)
I believe that KVM_GET_TSC_KHZ returns what userspace *asked* for the
TSC frequency to be (vcpu->arch.virtual_tsc_khz), not what it actually
ended up being based on the measured host frequency and the available
scaling granularity (vcpu->hw_tsc_khz).
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists