[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

> Jan


Oleksandr Tyshchenko

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.