[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v7 06/13] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data
[Public] > -----Original Message----- > From: Jan Beulich <jbeulich@xxxxxxxx> > Sent: Monday, August 25, 2025 11:02 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 v7 06/13] xen/cpufreq: introduce new sub-hypercall to > propagate CPPC data > > On 22.08.2025 12:52, Penny Zheng wrote: > > --- a/xen/arch/x86/x86_64/cpufreq.c > > +++ b/xen/arch/x86/x86_64/cpufreq.c > > @@ -54,3 +54,22 @@ int compat_set_px_pminfo(uint32_t acpi_id, > > > > return set_px_pminfo(acpi_id, xen_perf); } > > + > > +int compat_set_cppc_pminfo(unsigned int acpi_id, > > + const struct compat_processor_cppc > > +*cppc_data) > > + > > +{ > > + struct xen_processor_cppc *xen_cppc; > > + unsigned long xlat_page_current; > > + > > + xlat_malloc_init(xlat_page_current); > > + > > + xen_cppc = xlat_malloc_array(xlat_page_current, > > + struct xen_processor_cppc, 1); > > + if ( unlikely(xen_cppc == NULL) ) > > + return -EFAULT; > > I think we want to avoid repeating the earlier mistake with using a wrong > error code. > It's ENOMEM or ENOSPC or some such. > Understood, I'll change it to -ENOMEM > > --- a/xen/drivers/acpi/pm-op.c > > +++ b/xen/drivers/acpi/pm-op.c > > @@ -91,7 +91,9 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op) > > pmpt = processor_pminfo[op->cpuid]; > > policy = per_cpu(cpufreq_cpu_policy, op->cpuid); > > > > - if ( !pmpt || !pmpt->perf.states || > > + if ( !pmpt || > > + ((pmpt->init & XEN_PX_INIT) && !pmpt->perf.states) || > > + ((pmpt->init & XEN_CPPC_INIT) && pmpt->perf.state_count) || > > I fear I don't understand this: In the PX case we check whether necessary > data is > lacking. In the CPPC case you check that some data was provided that we don't > want to use? Why not similarly check that data we need was provided? > We are introducing another checking line for CPPC is actually to avoid NULL deref of state[i]: ``` for ( i = 0; i < op->u.get_para.freq_num; i++ ) data[i] = pmpt->perf.states[i].core_frequency * 1000; ``` We want to ensure "op->u.get_para.freq_num" is always zero in CPPC mode, which is validated against pmpt->perf.state_count. We have similar discussion in here https://old-list-archives.xen.org/archives/html/xen-devel/2025-06/msg01160.html > > Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |