Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen cmdline

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.05.2025 10:36, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Tuesday, April 29, 2025 8:52 PM
>> To: Penny, Zheng <penny.zheng@xxxxxxx>
>> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
>> <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD <anthony.perard@xxxxxxxxxx>;
>> Orzel, Michal <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Roger 
>> Pau
>> Monné <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; 
>> xen-
>> devel@xxxxxxxxxxxxxxxxxxxx
>> Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
>> cmdline
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/include/acpi/cpufreq/processor_perf.h
>>> +++ b/xen/include/acpi/cpufreq/processor_perf.h
>>> @@ -5,6 +5,9 @@
>>>  #include <public/sysctl.h>
>>>  #include <xen/acpi.h>
>>>
>>> +/* ability bits */
>>> +#define XEN_PROCESSOR_PM_CPPC   8
>>
>> This needs correlating (at least via commentary, better by build-time 
>> checking) with
>> the other XEN_PROCESSOR_PM_* values. Otherwise someone adding a new
>> #define in the public header may not (easily) notice a possible conflict. 
>> With that in
>> mind I also question whether 8 is actually a good choice: That's the obvious 
>> next
>> value to use in the public interface. SIF_PM_MASK is 8 bits wide, so a 
>> sensible
>> value to use here would by e.g. 0x100.
>>
> 
> I've added a public flag anchor "XEN_PROCESSOR_PM_PUBLIC_END" in public 
> header:
>          #define XEN_PROCESSOR_PM_PUBLIC_END    XEN_PROCESSOR_PM_TX
> and will do the following build-time checking:
>         BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC <= XEN_PROCESSOR_PM_PUBLIC_END);

I don't really see why anything would need to be added to the public
header (and we really should strive to avoid unnecessary additions).

Jan