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

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

Hi Jan

On Fri, Dec 8, 2017 at 10:07 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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.
Indeed "flags", sorry for being unclear.

>
>> 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.
Agree.

>
> Jan
>



-- 
Regards,

Oleksandr Tyshchenko

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