On 28.05.2021 15:19, Jason Andryuk wrote:
> On Thu, May 27, 2021 at 4:03 AM Jan Beulich wrote:
>> On 03.05.2021 21:28, Jason Andryuk wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -290,6 +290,12 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
>>> *op)
On Thu, May 27, 2021 at 4:03 AM Jan Beulich wrote:
>
> On 03.05.2021 21:28, Jason Andryuk wrote:
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -290,6 +290,12 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
> > *op)
> > &op->u.get_para.u.ondeman
On 03.05.2021 21:28, Jason Andryuk wrote:
> --- a/xen/arch/x86/acpi/cpufreq/hwp.c
> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> @@ -523,6 +523,30 @@ static const struct cpufreq_driver __initconstrel
> hwp_cpufreq_driver =
> .update = hwp_cpufreq_update,
> };
>
> +int get_hwp_para(struct cpufre
Extend xen_get_cpufreq_para to return hwp parameters. These match the
hardware rather closely.
We need the hw_features bitmask to indicated fields supported by the
actual hardware.
The use of uint8_t parameters matches the hardware size. uint32_t
entries grows the sysctl_t past the build assert
