[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45640c36-0b7d-4502-bf4d-df1c1d17d528@suse.com>
Date: Tue, 25 Mar 2025 17:17:03 +0100
From: Jan Beulich <jbeulich@...e.com>
To: Penny Zheng <Penny.Zheng@....com>, Roger Pau Monne <roger.pau@...rix.com>
Cc: Ray Huang <Ray.Huang@....com>, Jason Andryuk <jason.andryuk@....com>,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
Juergen Gross <jgross@...e.com>, Stefano Stabellini
<sstabellini@...nel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [PATCH v3 1/5] xen/acpi: upload power and performance related
data from a PVH dom0
On 06.03.2025 12:08, Penny Zheng wrote:
> From: Roger Pau Monne <roger.pau@...rix.com>
>
> When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to
> report the correct numbers of vCPUs that dom0 has, so the host MADT is
> not provided to dom0. This creates issues when parsing the power and
> performance related data from ACPI dynamic tables, as the ACPI
> Processor UIDs found on the dynamic code are likely to not match the
> ones crafted by Xen in the dom0 MADT.
>
> Xen would rely on Linux having filled at least the power and
> performance related data of the vCPUs on the system, and would clone
> that information in order to setup the remaining pCPUs on the system
> if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely
> that none of dom0 CPUs will have the power and performance data
> filled, and hence the Xen ACPI Processor driver needs to fetch that
> information by itself.
>
> In order to do so correctly, introduce a new helper to fetch the _CST
> data without taking into account the system capabilities from the
> CPUID output, as the capabilities reported to dom0 in CPUID might be
> different from the ones on the host.
>
> Note that the newly introduced code will only fetch the _CST, _PSS,
> _PPC and _PCT from a single CPU, and clone that information for all the
> other Processors. This won't work on an heterogeneous system with
> Processors having different power and performance related data between
> them.
>
> Signed-off-by: Roger Pau Monné <roger.pau@...rix.com>
> Signed-off-by: Jason Andryuk <jason.andryuk@....com>
> ---
> drivers/xen/pcpu.c | 3 +-
> drivers/xen/xen-acpi-processor.c | 232 ++++++++++++++++++++++++++++---
> include/xen/xen.h | 2 +-
> 3 files changed, 216 insertions(+), 21 deletions(-)
No dependency on another patch is mentioned anywhere (the cover letter
only says the series is based on the very patch here), yet the bulk of
the changes here (to drivers/xen/xen-acpi-processor.c) are meaningless
for a PVH Dom0, because of
config XEN_ACPI_PROCESSOR
tristate "Xen ACPI processor"
depends on XEN && XEN_PV_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
(note the XEN_PV_DOM0 in there). Is the patch here perhaps missing an
adjustment to the above, to use XEN_DOM0 instead?
Jan
Powered by blists - more mailing lists