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: <dae94ec2-79fd-43bd-a862-d06824fdf9ed@amd.com>
Date: Thu, 5 Dec 2024 15:19:47 -0500
From: Jason Andryuk <jason.andryuk@....com>
To: Penny Zheng <Penny.Zheng@....com>, Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <sstabellini@...nel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@...m.com>
CC: Ray Huang <Ray.Huang@....com>, Xenia Ragiadakou
	<Xenia.Ragiadakou@....com>, <xen-devel@...ts.xenproject.org>,
	<linux-kernel@...r.kernel.org>, Roger Pau Monne <roger.pau@...rix.com>
Subject: Re: [PATCH v2 1/4] xen/acpi: upload power and performance related
 data from a PVH dom0

On 2024-12-05 00:42, 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>

Hi Penny,

I think you should add your SoB since you are submitting on behalf of 
Roger and me.

Thanks,
Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ