From: Marc Zyngier <maz@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: David Dai <davidai@google.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Saravana Kannan <saravanak@google.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 v6 2/2] cpufreq: add virtual-cpufreq driver
Date: Wed, 10 Jul 2024 10:05:37 +0100 [thread overview]
Message-ID: <86wmlt39cu.wl-maz@kernel.org> (raw)
In-Reply-To: <20240628125106.i4hhyzdgt3uoskat@bogus>
On Fri, 28 Jun 2024 13:51:06 +0100,
Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Mon, May 20, 2024 at 09:30:52PM -0700, David Dai wrote:
> > Introduce a virtualized cpufreq driver for guest kernels to improve
> > performance and power of workloads within VMs.
> >
> > This driver does two main things:
> >
> > 1. Sends the frequency of vCPUs as a hint to the host. The host uses the
> > hint to schedule the vCPU threads and decide physical CPU frequency.
> >
> > 2. If a VM does not support a virtualized FIE(like AMUs), it queries the
> > host CPU frequency by reading a MMIO region of a virtual cpufreq device
> > to update the guest's frequency scaling factor periodically. This enables
> > accurate Per-Entity Load Tracking for tasks running in the guest.
> >
> > +
> > +/*
> > + * CPU0..CPUn
> > + * +-------------+-------------------------------+--------+-------+
> > + * | Register | Description | Offset | Len |
> > + * +-------------+-------------------------------+--------+-------+
> > + * | cur_perf | read this register to get | 0x0 | 0x4 |
> > + * | | the current perf (integer val | | |
> > + * | | representing perf relative to | | |
> > + * | | max performance) | | |
> > + * | | that vCPU is running at | | |
> > + * +-------------+-------------------------------+--------+-------+
> > + * | set_perf | write to this register to set | 0x4 | 0x4 |
> > + * | | perf value of the vCPU | | |
> > + * +-------------+-------------------------------+--------+-------+
> > + * | perftbl_len | number of entries in perf | 0x8 | 0x4 |
> > + * | | table. A single entry in the | | |
> > + * | | perf table denotes no table | | |
> > + * | | and the entry contains | | |
> > + * | | the maximum perf value | | |
> > + * | | that this vCPU supports. | | |
> > + * | | The guest can request any | | |
> > + * | | value between 1 and max perf | | |
> > + * | | when perftbls are not used. | | |
> > + * +---------------------------------------------+--------+-------+
> > + * | perftbl_sel | write to this register to | 0xc | 0x4 |
> > + * | | select perf table entry to | | |
> > + * | | read from | | |
> > + * +---------------------------------------------+--------+-------+
> > + * | perftbl_rd | read this register to get | 0x10 | 0x4 |
> > + * | | perf value of the selected | | |
> > + * | | entry based on perftbl_sel | | |
> > + * +---------------------------------------------+--------+-------+
> > + * | perf_domain | performance domain number | 0x14 | 0x4 |
> > + * | | that this vCPU belongs to. | | |
> > + * | | vCPUs sharing the same perf | | |
> > + * | | domain number are part of the | | |
> > + * | | same performance domain. | | |
> > + * +-------------+-------------------------------+--------+-------+
> > + */
>
> I think it is good idea to version this table, so that it gives flexibility
> to update the entries. It is a must if we are getting away with DT. I didn't
> give complete information in my previous response where I agreed with Rafael.
>
> I am not sure how much feasible it is, but can it be queried via KVM IOCTLs
> to VMM. Just a thought, I am exploring how to make this work even on ACPI
> systems. It is simpler if we neednot rely on DT or ACPI.
KVM should not have to know any of this. This is purely between a
contract (and a pretty weak one) between userspace and the guest.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-07-10 9:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 4:30 [PATCH v6 0/2] Improve VM CPUfreq and task placement behavior David Dai
2024-05-21 4:30 ` [PATCH v6 1/2] dt-bindings: cpufreq: add virtual cpufreq device David Dai
2024-05-22 15:00 ` Rob Herring (Arm)
2024-05-21 4:30 ` [PATCH v6 2/2] cpufreq: add virtual-cpufreq driver David Dai
2024-06-27 21:22 ` David Dai
2024-06-28 12:01 ` Rafael J. Wysocki
2024-06-28 12:42 ` Sudeep Holla
2024-07-10 0:07 ` Saravana Kannan
2024-08-30 22:51 ` David Dai
2024-06-28 12:51 ` Sudeep Holla
2024-07-10 9:05 ` Marc Zyngier [this message]
2024-05-21 7:41 ` [PATCH v6 0/2] Improve VM CPUfreq and task placement behavior Viresh Kumar
2024-05-22 18:22 ` David Dai
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=86wmlt39cu.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=krzk+dt@kernel.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@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).