Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.12.17 at 21:31, <olekstysh@xxxxxxxxx> wrote:
> Have questions which need to be clarified:
> 
> If I understood correctly, new variant of set_px_pminfo is going to
> have an extra "flag" argument, since
> struct processor_performance doesn't have "flag" field (it contains
> "state" field instead, which has yet another meaning).
> Something like that:
> int set_px_pminfo(uint32_t acpi_id, uint32_t flag, struct
> processor_performance *dom0_px_info)
> Is my understanding correct?

Well, you obviously must not lose information, so having that
extra parameter is unavoidable. Please use common sense
when dealing with such re-structuring. And btw, please also be
precise: There's no "flag" field, but there is a "flags" one. Such
should also be the name of the new parameter - we're talking
about multiple bits here, after all.

> As for set_cx_pminfo(). To what struct we should do translation from
> struct xen_processor_power? (struct acpi_processor_power?)

Yes, of course.

> Briefly looking at set_cx_pminfo(), I got a feeling, that in order to
> modify it in a "set_px_pminfo() manner"
> we need to rework print_cx_pminfo(),  set_cx(), check_cx(),
> acpi_processor_ffh_cstate_probe() too, since
> all these function have arguments which contain XEN_GUEST_HANDLE. I am
> wondering is it worth
> doing such rework taking into the account that set_cx_pminfo() is not
> going to be called from the non-hypercall context.
> Or I missed something?

Without looking at the details of this, please again use common
sense. If there are good reasons for the two functions to not
follow the same model, please simply state so in the overview
mail of the patch series and/or (briefly, but concisely) in the
specific patch's description. A good reason for example would
be if overly large amounts of other code would need touching.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel