From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [RFC PATCH v3 11/12] xen: arm: implement
	XEN_SYSCTL_cpufreq_op
Date: Thu, 23 Oct 2014 17:27:27 +0100
Message-ID: <54492C6F.8020806@linaro.org>
References: <1414076867-2148-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1414076867-2148-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1414076867-2148-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>, xen-devel@lists.xen.org
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>, Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hi Oleksandr,

On 10/23/2014 04:07 PM, Oleksandr Dmytryshyn wrote:
> Kernel uses this op to get some parameters for the
> xen-cpufreq driver to change CPUs frequency.

The XSM bit is missing for this new sysctl (see flask_sysctl).

> diff --git a/xen/drivers/cpufreq/hwdom-cpufreq.c b/xen/drivers/cpufreq/hwdom-cpufreq.c
> index 67c9e1d..cc97f37 100644
> --- a/xen/drivers/cpufreq/hwdom-cpufreq.c
> +++ b/xen/drivers/cpufreq/hwdom-cpufreq.c
> @@ -34,12 +34,53 @@ struct hwdom_cpufreq_data {
>  };
>  
>  static struct hwdom_cpufreq_data *hwdom_cpufreq_drv_data[NR_CPUS];
> +static DEFINE_SPINLOCK(sysctl_cpufreq_lock);
> +
> +struct sysctl_cpufreq_data {
> +    uint32_t cpu;
> +    uint32_t freq;
> +    uint32_t relation;
> +    int32_t result;
> +};
> +
> +static struct sysctl_cpufreq_data sysctl_cpufreq_data;
>  
>  int cpufreq_cpu_init(unsigned int cpuid)
>  {
>      return cpufreq_add_cpu(cpuid);
>  }
>  
> +static void notify_cpufreq_domains(void)
> +{
> +    send_global_virq(VIRQ_CPUFREQ);
> +}
> +
> +int sysctl_cpufreq_op(xen_sysctl_cpufreq_op_t *op)
> +{
> +    int ret = 0;

AFAIU, the cpufreq will always run in the hardware domain. Therefore,
shouldn't you check that the sysctl is effectively executed by this domain?

>  static int hwdom_cpufreq_verify(struct cpufreq_policy *policy)
>  {
>      struct hwdom_cpufreq_data *data;
> @@ -97,6 +138,17 @@ static int hwdom_cpufreq_target(struct cpufreq_policy *policy,
>      freqs.old = perf->states[perf->state].core_frequency * 1000;
>      freqs.new = data->freq_table[next_state].frequency;
>  
> +    /* Do send cmd for Dom0 */

s/Dom0/Hardware domain/

> +    spin_lock(&sysctl_cpufreq_lock);
> +    /* return previous result */
> +    ret = sysctl_cpufreq_data.result;
> +
> +    sysctl_cpufreq_data.cpu = policy->cpu;
> +    sysctl_cpufreq_data.freq = freqs.new;
> +    sysctl_cpufreq_data.relation = (uint32_t)relation;
> +    spin_unlock(&sysctl_cpufreq_lock);
> +    notify_cpufreq_domains();
> +
>      for_each_cpu( j, &online_policy_cpus )
>          cpufreq_statistic_update(j, perf->state, next_perf_state);
>  
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 8437d31..ecd4674 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -632,6 +632,23 @@ struct xen_sysctl_coverage_op {
>  typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
>  
> +#define XEN_SYSCTL_CPUFREQ_get_target      0
> +#define XEN_SYSCTL_CPUFREQ_set_result      1
> +
> +struct xen_sysctl_cpufreq_op {
> +    uint32_t cmd;
> +    union {
> +        struct {
> +            uint32_t cpu;
> +            uint32_t freq;
> +            uint32_t relation;
> +        } target;
> +        uint32_t result;
> +    } u;
> +};

Can you document this structure?

Regards,

-- 
Julien Grall