linux-kernel - Re: [PATCH v6 2/2] cpufreq: add virtual-cpufreq driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240628125106.i4hhyzdgt3uoskat@bogus>
Date: Fri, 28 Jun 2024 13:51:06 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: David Dai <davidai@...gle.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Quentin Perret <qperret@...gle.com>,
	Masami Hiramatsu <mhiramat@...gle.com>,
	Will Deacon <will@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Pavan Kondeti <quic_pkondeti@...cinc.com>,
	Gupta Pankaj <pankaj.gupta@....com>, Mel Gorman <mgorman@...e.de>,
	kernel-team@...roid.com, linux-pm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] cpufreq: add virtual-cpufreq driver

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.

--
Regards,
Sudeep