[Public]
> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: Tuesday, April 29, 2025 8:52 PM
> To: Penny, Zheng <[email protected]>
> Cc: Huang, Ray <[email protected]>; Andrew Cooper
> <[email protected]>; Anthony PERARD <[email protected]>;
> Orzel, Michal <[email protected]>; Julien Grall <[email protected]>; Roger Pau
> Monné <[email protected]>; Stefano Stabellini <[email protected]>;
> xen-
> [email protected]
> 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);
> Jan
