From: Marc Zyngier <maz@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: David Dai <davidai@google.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Quentin Perret <qperret@google.com>,
Masami Hiramatsu <mhiramat@google.com>,
Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Oliver Upton <oliver.upton@linux.dev>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Pavan Kondeti <quic_pkondeti@quicinc.com>,
Gupta Pankaj <pankaj.gupta@amd.com>, Mel Gorman <mgorman@suse.de>,
kernel-team@android.com, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: cpufreq: add virtual cpufreq device
Date: Fri, 08 Dec 2023 08:52:50 +0000 [thread overview]
Message-ID: <867clpaxel.wl-maz@kernel.org> (raw)
In-Reply-To: <CAGETcx9-n0z5buWgtLZ+6VxW2jEko1GWzkGtGhFiZEq-x_G4nw@mail.gmail.com>
On Thu, 07 Dec 2023 22:44:36 +0000,
Saravana Kannan <saravanak@google.com> wrote:
>
> On Wed, Nov 15, 2023 at 12:49 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Sat, 11 Nov 2023 01:49:29 +0000,
> > David Dai <davidai@google.com> wrote:
> > >
> > > Adding bindings to represent a virtual cpufreq device.
> > >
> > > Virtual machines may expose MMIO regions for a virtual cpufreq device
> > > for guests to read frequency information or to request frequency
> > > selection. The virtual cpufreq device has an individual controller for
> > > each frequency domain.
> >
> > I would really refrain form having absolute frequencies here. A
> > virtual machine can be migrated, and there are *zero* guarantees that
> > the target system has the same clock range as the source.
> >
> > This really should be a relative number, much like the capacity. That,
> > at least, can be migrated across systems.
>
> There's nothing in this patch that mandates absolute frequency.
> In true KVM philosophy, we leave it to the VMM to decide.
This has nothing to do with KVM. It would apply to any execution
environment, including QEMU in TCG mode.
To quote the original patch:
+ description:
+ Address and size of region containing frequency controls for each of the
+ frequency domains. Regions for each frequency domain is placed
+ contiugously and contain registers for controlling DVFS(Dynamic Frequency
+ and Voltage) characteristics. The size of the region is proportional to
+ total number of frequency domains.
What part of that indicates that *relative* frequencies are
acceptable? The example explicitly uses the opp-v2 binding, which
clearly is about absolute frequency.
To reiterate: absolute frequencies are not the right tool for the job,
and they should explicitly be described as relative in the spec. Not
left as a "whatev'" option for the execution environment to interpret.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2023-12-08 8:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-11 1:49 [PATCH v4 0/2] Improve VM CPUfreq and task placement behavior David Dai
2023-11-11 1:49 ` [PATCH v4 1/2] dt-bindings: cpufreq: add virtual cpufreq device David Dai
2023-11-15 6:27 ` Viresh Kumar
2023-11-16 16:22 ` Rob Herring
2023-11-15 8:49 ` Marc Zyngier
2023-12-07 22:44 ` Saravana Kannan
2023-12-08 8:52 ` Marc Zyngier [this message]
2024-01-12 22:02 ` Saravana Kannan
2024-01-13 9:37 ` Marc Zyngier
2024-01-16 23:47 ` Saravana Kannan
2023-12-08 12:45 ` Sudeep Holla
2024-01-12 22:15 ` Saravana Kannan
2024-01-15 16:28 ` Hongyan Xia
2023-11-11 1:49 ` [PATCH v4 2/2] cpufreq: add virtual-cpufreq driver David Dai
2023-11-15 6:29 ` Viresh Kumar
2023-12-08 1:18 ` David Dai
2023-12-08 9:51 ` Viresh Kumar
2024-01-15 16:58 ` Hongyan Xia
2023-11-13 12:20 ` [PATCH v4 0/2] Improve VM CPUfreq and task placement behavior Hongyan Xia
2023-11-13 12:26 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867clpaxel.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=conor+dt@kernel.org \
--cc=davidai@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mhiramat@google.com \
--cc=oliver.upton@linux.dev \
--cc=pankaj.gupta@amd.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=quic_pkondeti@quicinc.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).