linux-kernel - Re: [PATCH v3 1/5] xen/acpi: upload power and performance related data from a PVH dom0

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: <92b5c3ae-716c-4ea1-95f5-65150fccf39f@amd.com>
Date: Tue, 25 Mar 2025 12:49:29 -0400
From: Jason Andryuk <jason.andryuk@....com>
To: Jan Beulich <jbeulich@...e.com>, Penny Zheng <Penny.Zheng@....com>, "Roger
 Pau Monne" <roger.pau@...rix.com>
CC: Ray Huang <Ray.Huang@....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 2025-03-25 12:17, Jan Beulich wrote:
> 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?

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