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 wrote: On 07.12.17 at 21:31, 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 >>

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

Hi, Stefano, Jan On Thu, Dec 7, 2017 at 10:45 AM, Jan Beulich wrote: On 07.12.17 at 00:44, wrote: >> Oleksandr would like to call set_px_pminfo from a non-hypercall context, >> meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct

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

>>> On 07.12.17 at 00:44, wrote: > Oleksandr would like to call set_px_pminfo from a non-hypercall context, > meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct > xen_processor_performance contains a > > XEN_GUEST_HANDLE(xen_processor_px_t) states; >

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

>>> On 05.12.17 at 21:48, wrote: > You are right. We need to define a new struct for internal usage, for > example: > > struct xen_processor_performance_internal { > uint32_t flags; /* flag for Px sub info type */ > uint32_t platform_limit; /* Platform

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

Hi Stefano On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini wrote: > On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote: >> Hi, Stefano >> >> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini >> wrote: >> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko

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

Hi, Stefano On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini wrote: > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote: >> From: Oleksandr Dmytryshyn >> >> First implementation of the cpufreq driver has been >> written with x86 in