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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.