Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.06.2025 06:18, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Thursday, June 12, 2025 12:10 AM
>> 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 v5 04/18] xen/cpufreq: introduce new sub-hypercall to
>> propagate CPPC data
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> @@ -635,6 +641,124 @@ out:
>>>      return ret;
>>>  }
>>>
>>> +static void print_CPPC(const struct xen_processor_cppc *cppc_data) {
>>> +    printk("\t_CPC: highest_perf=%u, lowest_perf=%u, "
>>> +           "nominal_perf=%u, lowest_nonlinear_perf=%u, "
>>> +           "nominal_mhz=%uMHz, lowest_mhz=%uMHz\n",
>>> +           cppc_data->cpc.highest_perf, cppc_data->cpc.lowest_perf,
>>> +           cppc_data->cpc.nominal_perf, 
>>> cppc_data->cpc.lowest_nonlinear_perf,
>>> +           cppc_data->cpc.nominal_mhz, cppc_data->cpc.lowest_mhz); }
>>> +
>>> +int set_cppc_pminfo(unsigned int acpi_id,
>>> +                    const struct xen_processor_cppc *cppc_data) {
>>> +    int ret = 0, cpuid;
>>> +    struct processor_pminfo *pm_info;
>>> +
>>> +    cpuid = get_cpu_id(acpi_id);
>>> +    if ( cpuid < 0 || !cppc_data )
>>
>> The !cppc_data part isn't really needed, is it?
> 
> I added it because set_cppc_pminfo() is an external function, and maybe we 
> shall validate each
> input for any external functions? Or maybe not. I'm not sure if it is a MUST?

It's not. If look through code globally, it is rare that we have such checks.
Many of them are imo pointless (and thus giving bad examples). In certain
cases they're meaningful to have.

>>> +        pm_info->init = XEN_CPPC_INIT;
>>> +        ret = cpufreq_cpu_init(cpuid); #ifndef NDEBUG
>>> +        if ( ret )
>>> +            dprintk(XENLOG_WARNING,
>>> +                    "CPU %u failed to be initialized with amd-cppc mode, 
>>> and users
>> could only reboot and re-define cmdline with \"cpufreq=xen\"",
>>> +                    cpuid);
>>> +#endif
>>
>> What use if the #ifdef here? The more that NDEBUG controls behavior of
>> ASSERT(), not that of (debug) logging.
> 
> Understood. Maybe I shall use one-time printk_once()

Perhaps, also considering that the action to take is relevant also in
release builds. However, "users could only" is once again odd wording for
a log message. How about "CPU%u failed amd-cppc mode init; use \"cpufreq=xen\"
instead"?

Jan