[Public]
> -----Original Message-----
> From: Jan Beulich <jbeul...@suse.com>
> Sent: Thursday, August 28, 2025 3:09 PM
> To: Penny, Zheng <penny.zh...@amd.com>
> Cc: Huang, Ray <ray.hu...@amd.com>; Anthony PERARD
> <anthony.per...@vates.tech>; Andrew Cooper <andrew.coop...@citrix.com>;
> Orzel, Michal <michal.or...@amd.com>; Julien Grall <jul...@xen.org>; Roger Pau
> Monné <roger....@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>;
> xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v7 13/13] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
> xen_sysctl_pm_op for amd-cppc driver
>
> On 28.08.2025 08:54, Penny, Zheng wrote:
> > [Public]
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeul...@suse.com>
> >> Sent: Thursday, August 28, 2025 2:38 PM
> >> To: Penny, Zheng <penny.zh...@amd.com>
> >> Cc: Huang, Ray <ray.hu...@amd.com>; Anthony PERARD
> >> <anthony.per...@vates.tech>; Andrew Cooper
> >> <andrew.coop...@citrix.com>; Orzel, Michal <michal.or...@amd.com>;
> >> Julien Grall <jul...@xen.org>; Roger Pau Monné
> >> <roger....@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>;
> >> xen- de...@lists.xenproject.org
> >> Subject: Re: [PATCH v7 13/13] xen/cpufreq: Adapt
> SET/GET_CPUFREQ_CPPC
> >> xen_sysctl_pm_op for amd-cppc driver
> >>
> >> On 28.08.2025 08:35, Jan Beulich wrote:
> >>> On 28.08.2025 06:06, Penny, Zheng wrote:
> >>>>> -----Original Message-----
> >>>>> From: Jan Beulich <jbeul...@suse.com>
> >>>>> Sent: Tuesday, August 26, 2025 12:03 AM
> >>>>>
> >>>>> On 22.08.2025 12:52, Penny Zheng wrote:
> >>>>>> --- a/xen/include/public/sysctl.h
> >>>>>> +++ b/xen/include/public/sysctl.h
> >>>>>> @@ -336,8 +336,14 @@ struct xen_ondemand {
> >>>>>> uint32_t up_threshold;
> >>>>>> };
> >>>>>>
> >>>>>> +#define CPUFREQ_POLICY_UNKNOWN 0
> >>>>>> +#define CPUFREQ_POLICY_POWERSAVE 1
> >>>>>> +#define CPUFREQ_POLICY_PERFORMANCE 2
> >>>>>> +#define CPUFREQ_POLICY_ONDEMAND 3
> >>>>>
> >>>>> Without XEN_ prefixes they shouldn't appear in a public header.
> >>>>> But do we need ...
> >>>>>
> >>>>>> struct xen_get_cppc_para {
> >>>>>> /* OUT */
> >>>>>> + uint32_t policy; /* CPUFREQ_POLICY_xxx */
> >>>>>
> >>>>> ... the new field at all? Can't you synthesize the
> >>>>> kind-of-governor into struct xen_get_cpufreq_para's respective
> >>>>> field? You invoke both sub-ops from xenpm now anyway ...
> >>>>>
> >>>>
> >>>> Maybe I could borrow governor field to indicate policy info, like
> >>>> the following in
> >> print_cpufreq_para(), then we don't need to add the new filed "policy"
> >>>> ```
> >>>> + /* Translate governor info to policy info in CPPC active mode */
> >>>> + if ( is_cppc_active )
> >>>> + {
> >>>> + if ( !strncmp(p_cpufreq->u.s.scaling_governor,
> >>>> + "ondemand", CPUFREQ_NAME_LEN) )
> >>>> + printf("cppc policy : ondemand\n");
> >>>> + else if ( !strncmp(p_cpufreq->u.s.scaling_governor,
> >>>> + "performance", CPUFREQ_NAME_LEN) )
> >>>> + printf("cppc policy : performance\n");
> >>>> +
> >>>> + else if ( !strncmp(p_cpufreq->u.s.scaling_governor,
> >>>> + "powersave", CPUFREQ_NAME_LEN) )
> >>>> + printf("cppc policy : powersave\n");
> >>>> + else
> >>>> + printf("cppc policy : unknown\n");
> >>>> + }
> >>>> +
> >>>> ```
> >>>
> >>> Something like this is what I was thinking of, yes.
> >>
> >> Albeit - why the complicated if/else sequence? Why not simply print
> >> the field the hypercall returned?
> >
> > userspace governor doesn't have according policy. I could simplify it
> > to ```
> > if ( !strncmp(p_cpufreq->u.s.scaling_governor,
> > "userspace", CPUFREQ_NAME_LEN) )
> > printf("policy : unknown\n");
> > else
> > printf("policy : %s\n",
> > p_cpufreq->u.s.scaling_governor); ```
>
> But the hypervisor shouldn't report back "userspace" when the CPPC driver is
> in
> use. ANd I think the tool is okay to trust the hypervisor.
True, we shall make sure governor is set properly in hypervisor side even in
cppc mode
>
> Jan
