Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Subject: RE: ...\n
Thread-Topic: ...\n
From:   "Durrant, Paul" <pdurrant@amazon.co.uk>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>
CC:     "Allister, Jack" <jalliste@amazon.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "diapop@amazon.co.uk" <diapop@amazon.co.uk>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "jmattson@google.com" <jmattson@google.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "metikaya@amazon.co.uk" <metikaya@amazon.co.uk>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "rkrcmar@redhat.com" <rkrcmar@redhat.com>,
        "sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "wanpengli@tencent.com" <wanpengli@tencent.com>,
        "x86@kernel.org" <x86@kernel.org>
Thread-Index: AQHYdPhkNX+wk5QumkS6hY2ybmOpva05D+WAgAABcbCAAQ0lgIAAE6AAgAALn5A=
Date:   Wed, 1 Jun 2022 08:54:08 +0000
Message-ID: <48edf12807254a2b86e339b26873bf00@EX13D32EUC003.ant.amazon.com>
References: <YpYaYK7a28DFT5Ne@hirez.programming.kicks-ass.net>
 <20220531140236.1435-1-jalliste@amazon.com>
 <YpYpxzt4rmG+LFy9@hirez.programming.kicks-ass.net>
 <059ab3327ac440479ecfdf49fa054347@EX13D32EUC003.ant.amazon.com>
 <YpcMw2TgNWzrcoRm@worktop.programming.kicks-ass.net>
 <87r148olol.fsf@redhat.com>
In-Reply-To: <87r148olol.fsf@redhat.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

> -----Original Message-----
[snip]
> >>
> >> I'll bite... What's ludicrous about wanting to run a guest at a lower
> >> CPU freq to minimize observable change in whatever workload it is
> >> running?
> >
> > *why* would you want to do that? Everybody wants their stuff done
> > faster.
> >
>=20
> FWIW, I can see a valid use-case: imagine you're running some software
> which calibrates itself in the beginning to run at some desired real
> time speed but then the VM running it has to be migrated to a host with
> faster (newer) CPUs. I don't have a real world examples out of top of my
> head but I remember some old DOS era games were impossible to play on
> newer CPUs because everything was happenning too fast. Maybe that's the
> case :-)
>=20

That is exactly the case. This is not 'some hare-brained money scheme'; the=
re is genuine concern that moving a VM from old h/w to new h/w may cause it=
 to run 'too fast', breaking any such calibration done by the guest OS/appl=
ication. I also don't have any real-world examples, but bugs may well be re=
ported and having a lever to address them is IMO a good idea.
However, I also agree with Paolo that KVM doesn't really need to be doing t=
his when the VMM could do the job using cpufreq, so we'll pursue that optio=
n instead. (FWIW the reason for involving KVM was to do the freq adjustment=
 right before entering the guest and then remove the cap right after VMEXIT=
).

  Paul