RE: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0
From: Penny, Zheng
Date: Thu Dec 05 2024 - 00:24:20 EST
[AMD Official Use Only - AMD Internal Distribution Only]
Hi,
> -----Original Message-----
> From: Jason Andryuk <jason.andryuk@xxxxxxx>
> Sent: Thursday, December 5, 2024 3:12 AM
> To: Jürgen Groß <jgross@xxxxxxxx>; Penny, Zheng <penny.zheng@xxxxxxx>;
> Stefano Stabellini <sstabellini@xxxxxxxxxx>; Oleksandr Tyshchenko
> <oleksandr_tyshchenko@xxxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Ragiadakou, Xenia
> <Xenia.Ragiadakou@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Subject: Re: [PATCH v1 1/4] xen/acpi: upload power and performance related data
> from a PVH dom0
>
> On 2024-12-04 03:29, Jürgen Groß wrote:
> > On 04.12.24 09:24, Penny Zheng wrote:
> >> From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >>
> >> 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@xxxxxxxxxx>
> >> Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> >
> > I think this is the V2 version of Jason's patch, of which he sent V3
> > just yesterday?
>
> Penny's patch has some of the changes I made, but then I made an additional
> change and didn't tell her about it.
>
> > Please sync with him how to proceed: is his patch meant to be a
> > prerequisite for your series or a part of it?
>
> Sorry for the confusion. Penny, I think you should just grab my v3
> (https://lore.kernel.org/xen-devel/20241203225338.1336-1-
> jason.andryuk@xxxxxxx/T/#u)
> and resubmit with that. It removes a BUG_ON that checkpatch complained about
> (which is unreachable because of an earlier NULL check).
>
Sure, I'm downloading your version, and will rebase and push a new version here~
> Thanks,
> Jason
Mant thx,
Penny