[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLl_MAk9AT5hRuoS@google.com>
Date: Thu, 4 Sep 2025 04:59:44 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: David Woodhouse <dwmw2@...radead.org>
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 Tue, Sep 02, 2025, David Woodhouse wrote:
> On Tue, 2025-09-02 at 10:49 -0700, Sean Christopherson wrote:
> >
> > > So even if a VMM has set the TSC frequency VM-wide with KVM_SET_TSC_KHZ
> > > instead of doing it the old per- vCPU way, how can it get the results for a
> > > specific VM?
> >
> > I don't see any need for userspace to query per-VM support. What I'm proposing
> > is that KVM advertise the feature if the bare metal TSC is constant and the CPU
> > supports TSC scaling. Beyond that, _KVM_ doesn't need to do anything to ensure
> > the guest sees a constant frequency, it's userspace's responsibility to provide
> > a sane configuration.
> >
> > And strictly speaking, CPUID is per-CPU, i.e. it's architecturally legal to set
> > per-vCPU frequencies and then advertise a different frequency in CPUID for each
> > vCPU. That's all but guaranteed to break guests as most/all kernels assume that
> > TSC operates at the same frequency on all CPUs, but as above, that's userspace's
> > responsibility to not screw up.
>
> Sure, but doesn't that make this whole thing orthogonal to the original
> problem being solved? Because userspace still doesn't *know* the actual
> effective TSC frequency, whether it's scaled or not.
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)
> Or are you suggesting that we add the leaf (with unscaled values) in
> KVM_GET_SUPPORTED_CPUID and *also* 'correct' the values if userspace
> does pass that leaf to its guests, as I had originally proposed?
The effective guest TSC frequency should be whatever is reported in KVM_GET_TSC_KHZ
when done on a vCPU, modulo temporarily skewed results without hardware scaling.
If that doesn't hold true, we should fix that.
Powered by blists - more mailing lists