[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to propagate CPPC data


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Penny, Zheng" <penny.zheng@xxxxxxx>
  • Date: Tue, 6 May 2025 09:11:01 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6A3uaH0VVPxzCGmuST5QWIYz6b0JbRau4C/+yRuexQo=; b=gTiRzxp2FRKpLYuwFpiANSS2gwJRFZsAUPM6segZiIdWmXWw+S3IuLvtfH7N+RFOgfTFqVVlSJGKbG23Y0Hzf048vObhRtik70cotv2On1c4bOQNtlch070um1PvhNVkGaIrcLGy1rra5Iwu5efyfrYV7KlOuVPEM+DgBJhiScCFQEWs/kxU7J3Gs7dfayf8fNKyUU8a23HLn5TliCN7Avhgcexi+70/ebVU27w3AqjNO2BGF5jDHeJHDUF6J5cBJwan1jr0Z/GUNpb2RbRnUnGsN/BFTaGjhx/Le4YEHFsvdx46geaaF6XBQ1dQIj2EtdK+jUEVym6vg/ZOh5T8Cw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L2EI/raqi3TkcuhY0jhHc6aGB4h4/ZSwUQAqTmQ22d1BMRbFrEXqLkv600GadQ9oppva4rPUQFFOUIHlFKHbndqG4SvLMzrK8AqdZT4L1ulXe+M5iszQgL1Pvc8A/2zb9NozfQfQJOSHa+wWIqgP9d8KuvLBX6uesKVLaWFUQzs8EwoleV+cQHRspcupkbt7XH+MdlvhkOV43Pw+wq3PGCxqySHqoVKtM0uQWAXX8aPYiJ0MoTAoiX6V6R9MbkRmUU54dSeI6LvphuGfqhMgRB+uh6zY1OMWJGZquVGtHP075PEEpOEm5TDQXjN5l+V0BIWp6PVKSluyowwdHh13kA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Orzel, Michal" <Michal.Orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 06 May 2025 09:11:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=a2e2940d-15e5-4846-bbe2-5a87bdc763f5;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T09:10:54Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10, 0, 1, 1;
  • Thread-index: AQHbrRCmWPNHyarMuUaK4nZ2TXIaALO5UliAgAwK3VA=
  • Thread-topic: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to propagate CPPC data

[Public]

HI

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Monday, April 28, 2025 11:57 PM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Orzel, Michal
> <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to 
> propagate
> CPPC data
>
> On 14.04.2025 09:40, Penny Zheng wrote:
> > +    if ( cppc_data->flags & XEN_CPPC_CPC )
> > +    {
> > +        if ( cppc_data->cpc.highest_perf == 0 ||
> > +             cppc_data->cpc.highest_perf > UINT8_MAX ||
> > +             cppc_data->cpc.nominal_perf == 0 ||
> > +             cppc_data->cpc.nominal_perf > UINT8_MAX ||
> > +             cppc_data->cpc.lowest_nonlinear_perf == 0 ||
> > +             cppc_data->cpc.lowest_nonlinear_perf > UINT8_MAX ||
> > +             cppc_data->cpc.lowest_perf == 0 ||
> > +             cppc_data->cpc.lowest_perf > UINT8_MAX ||
> > +             cppc_data->cpc.lowest_perf >
> > +                cppc_data->cpc.lowest_nonlinear_perf ||
>
> Where's this ordering spelled out in the spec?
>

Clip a snippet from description on lowest performance[1], we may deduce that
```
Selecting a performance level lower than the lowest nonlinear performance level 
may actually cause an efficiency penalty,
but should reduce the instantaneous power consumption of the processor
```
lowest is smaller than lowest nonlinear

> > +             cppc_data->cpc.lowest_nonlinear_perf >
> > +                cppc_data->cpc.nominal_perf ||
> > +             cppc_data->cpc.nominal_perf > cppc_data->cpc.highest_perf )
> > +            /*
> > +             * Right now, Xen doesn't actually use perf values
> > +             * in ACPI _CPC table, warning is enough.
> > +             */
> > +            printk(XENLOG_WARNING
> > +                   "Broken CPPC perf values: lowest(%u), 
> > nonlinear_lowest(%u),
> nominal(%u), highest(%u)\n",
> > +                   cppc_data->cpc.lowest_perf,
> > +                   cppc_data->cpc.lowest_nonlinear_perf,
> > +                   cppc_data->cpc.nominal_perf,
> > +                   cppc_data->cpc.highest_perf);
>
> If this warning was to ever surface, it would likely surface for every CPU.
> That's unnecessarily verbose, I guess. Please consider using printk_once() 
> here.
>

Understood

> Also, is "right now" (as the comment says) still going to be true by the end 
> of the
> series? Didn't I see you use the values in earlier versions?
>

The reason why I added this comment is that in current implementation, we 
actually
don't use values read from ACPI _CPC table for lowest_perf, 
lowest_nonlinear_perf,
nominal_perf, and highest_perf.
We read CPPC capability MSR to get these four values.
What we actually use is the following optional lowest_mhz and nominal_mhz. We 
read
these two values for perf_to_khz transition.

There are two ways to read CPPC capability info, one is from MSR register, and 
the other is from
_CPC table. Only in very few hardware, MSR is not supported, and we must switch 
to use ACPI _CPC
Such scenario is not covered in this patch serie. I've mentioned it in the 
cover letter.
The difficulty actually is that when we try to use ACPI _CPC to do CPPC 
performance monitoring,
some control registers are probably implemented in the Platform Communications 
Channel (PCC) interface, which
is not supported in Xen.

> > +
> > +    if ( cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC) )
>
> If either flag may be clear, ...
>
> > +    {
> > +        pm_info->cppc_data = *cppc_data;
> > +        if ( cpufreq_verbose )
> > +        {
> > +            print_PSD(&pm_info->cppc_data.domain_info);
> > +            print_CPPC(&pm_info->cppc_data);
>
> ... why unconditionally loog both?
>
> > +        }
> > +
> > +        pm_info->init = XEN_CPPC_INIT;
>
> Plus is it correct to set this flag if either of the incoming flags was clear?
>

Hmm, I may not understand what you mean here...
I log and set this flag only when both flags are set (cppc_data->flags == 
(XEN_CPPC_PSD | XEN_CPPC_CPC))
_PSD entry and _CPC entry are both mandatory
Did you suggest that we shall give warning message when either flag is clear?

> Jan

[1] 
https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html?highlight=cppc#lowest-performance

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.