[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0
[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |