From: Hongyan Xia <hongyan.xia2@arm.com>
To: 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>,
Saravana Kannan <saravanak@google.com>
Cc: 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>,
Marc Zyngier <maz@kernel.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: Mon, 15 Jan 2024 16:28:13 +0000 [thread overview]
Message-ID: <f2e94d3b-bf2e-492f-a72d-f7978125d7d4@arm.com> (raw)
In-Reply-To: <20231111014933.1934562-2-davidai@google.com>
On 11/11/2023 01:49, David Dai 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.
>
> Co-developed-by: Saravana Kannan <saravanak@google.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Signed-off-by: David Dai <davidai@google.com>
> ---
> .../cpufreq/qemu,cpufreq-virtual.yaml | 99 +++++++++++++++++++
> 1 file changed, 99 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml b/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml
> new file mode 100644
> index 000000000000..16606cf1fd1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/qemu,cpufreq-virtual.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/qemu,cpufreq-virtual.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Virtual CPUFreq
> +
> +maintainers:
> + - David Dai <davidai@google.com>
> + - Saravana Kannan <saravanak@google.com>
> +
> +description:
> + Virtual CPUFreq is a virtualized driver in guest kernels that sends frequency
> + selection of its vCPUs as a hint to the host through MMIO regions. Each vCPU
> + is associated with a frequency domain which can be shared with other vCPUs.
> + Each frequency domain has its own set of registers for frequency controls.
> +
> +properties:
> + compatible:
> + const: qemu,virtual-cpufreq
> +
> + reg:
> + maxItems: 1
> + 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.
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + // This example shows a two CPU configuration with a frequency domain
> + // for each CPU.
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "arm,armv8";
> + device_type = "cpu";
> + reg = <0x0>;
> + operating-points-v2 = <&opp_table0>;
> + };
> +
> + cpu@1 {
> + compatible = "arm,armv8";
> + device_type = "cpu";
> + reg = <0x0>;
> + operating-points-v2 = <&opp_table1>;
> + };
> + };
> +
> + opp_table0: opp-table-0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp1098000000 {
> + opp-hz = /bits/ 64 <1098000000>;
> + opp-level = <1>;
> + };
> +
> + opp1197000000 {
> + opp-hz = /bits/ 64 <1197000000>;
> + opp-level = <2>;
> + };
> + };
> +
> + opp_table1: opp-table-1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp1106000000 {
> + opp-hz = /bits/ 64 <1106000000>;
> + opp-level = <1>;
> + };
> +
> + opp1277000000 {
> + opp-hz = /bits/ 64 <1277000000>;
> + opp-level = <2>;
> + };
> + };
NIT: If my understanding is correct, it might be worth re-iterating that
these OPPs should mirror the host frequency domain this vCPU is pinned to.
Also, since VM migration has been mentioned elsewhere in this thread, am
I right in saying that you can't change these OPPs after registration?
So, even if one wants to migrate, one has to migrate to an SoC with the
same frequency domains anyway, otherwise the OPPs in the VM are entirely
bogus?
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpufreq@1040000 {
> + compatible = "qemu,virtual-cpufreq";
> + reg = <0x1040000 0x10>;
> + };
> + };
next prev parent reply other threads:[~2024-01-15 16:28 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
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 [this message]
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=f2e94d3b-bf2e-492f-a72d-f7978125d7d4@arm.com \
--to=hongyan.xia2@arm.com \
--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=maz@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).