From: Jason Andryuk <jason.andryuk@amd.com>
To: Jan Beulich <jbeulich@suse.com>,
Penny Zheng <Penny.Zheng@amd.com>,
"Roger Pau Monne" <roger.pau@citrix.com>
Cc: Ray Huang <Ray.Huang@amd.com>, <xen-devel@lists.xenproject.org>,
<linux-kernel@vger.kernel.org>, Juergen Gross <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH v3 1/5] xen/acpi: upload power and performance related data from a PVH dom0
Date: Tue, 25 Mar 2025 12:49:29 -0400 [thread overview]
Message-ID: <92b5c3ae-716c-4ea1-95f5-65150fccf39f@amd.com> (raw)
In-Reply-To: <45640c36-0b7d-4502-bf4d-df1c1d17d528@suse.com>
On 2025-03-25 12:17, Jan Beulich wrote:
> On 06.03.2025 12:08, Penny Zheng wrote:
>> From: Roger Pau Monne <roger.pau@citrix.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@citrix.com>
>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.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?
Wow, I'm surprised you found that :) Yes, that is a build-time
dependency, but the runtime dependency is only on xen_initial_domain().
Yes, it deserves updating.
Thanks,
Jason
next prev parent reply other threads:[~2025-03-25 16:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 11:08 [PATCH v3 0/5] xen/acpi: introduce cppc performance hypercall Penny Zheng
2025-03-06 11:08 ` [PATCH v3 1/5] xen/acpi: upload power and performance related data from a PVH dom0 Penny Zheng
2025-03-25 16:17 ` Jan Beulich
2025-03-25 16:49 ` Jason Andryuk [this message]
2025-03-25 21:11 ` Elliott Mitchell
2025-03-06 11:08 ` [PATCH v3 2/5] xen: introduces XEN_PM_PSD sub-hypercall for solely delivery of _PSD info Penny Zheng
2025-03-06 11:08 ` [PATCH v3 3/5] acpi/cppc: extract _cpc entry parsing logic Penny Zheng
2025-03-06 11:08 ` [PATCH v3 4/5] xen/cppc: get xen-required cppc perf caps data Penny Zheng
2025-03-06 11:08 ` [PATCH v3 5/5] xen/cppc: introduce cppc data upload sub-hypercall Penny Zheng
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=92b5c3ae-716c-4ea1-95f5-65150fccf39f@amd.com \
--to=jason.andryuk@amd.com \
--cc=Penny.Zheng@amd.com \
--cc=Ray.Huang@amd.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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
all inboxes | Powered by JetHome®