All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Yi Sun <yi.y.sun@linux.intel.com>
Cc: xen-devel@lists.xenproject.org,
	Julien Grall <julien.grall@arm.com>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2] x86: psr: support co-exist features' values setting
Date: Mon, 9 Oct 2017 15:03:25 +0100	[thread overview]
Message-ID: <20171009140325.nex4ernpmra5brxz@dhcp-3-128.uk.xensource.com> (raw)
In-Reply-To: <1507436520-5629-1-git-send-email-yi.y.sun@linux.intel.com>

On Sun, Oct 08, 2017 at 04:22:00AM +0000, Yi Sun wrote:
> It changes the memebers in 'cos_write_info' to transfer the feature array,
> feature properties array and value array. Then, we can write all features
> values on the cos id into MSRs.
> 
> Because multiple features may co-exist, we need handle all features to write
> values of them into a COS register with new COS ID. E.g:
> 1. L3 CAT and L2 CAT co-exist.
> 2. Dom1 and Dom2 share the same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
>    the L2 CAT CBM of Dom1 is 0x1f.
> 3. User wants to change L2 CBM of Dom1 to be 0xf. Because COS ID 2 is
>    used by Dom2 too, we have to pick a new COS ID 3. The values of Dom1 on
>    COS ID 3 are all default values as below:
>            ---------
>            | COS 3 |
>            ---------
>    L3 CAT  | 0x7ff |
>            ---------
>    L2 CAT  | 0xff  |
>            ---------
> 4. After setting, the L3 CAT CBM value of Dom1 should be kept and the new L2
>    CAT CBM is set. So, the values on COS ID 3 should be below.
>            ---------
>            | COS 3 |
>            ---------
>    L3 CAT  | 0x1ff |
>            ---------
>    L2 CAT  | 0xf   |
>            ---------
> 
> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>  xen/arch/x86/psr.c | 54 ++++++++++++++++++++++++++++++------------------------
>  1 file changed, 30 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index daa2aeb..dbf7a4c 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -1111,25 +1111,43 @@ static unsigned int get_socket_cpu(unsigned int socket)
>  struct cos_write_info
>  {
>      unsigned int cos;
> -    struct feat_node *feature;
> +    struct feat_node **features;
>      const uint32_t *val;
> -    const struct feat_props *props;
> +    unsigned int array_len;
>  };
>  
>  static void do_write_psr_msrs(void *data)

Should this be "static int do_write_psr_msrs"...

>  {
>      const struct cos_write_info *info = data;
> -    struct feat_node *feat = info->feature;
> -    const struct feat_props *props = info->props;
> -    unsigned int i, cos = info->cos, cos_num = props->cos_num;
> +    unsigned int i, index = 0, cos = info->cos;
>  
> -    for ( i = 0; i < cos_num; i++ )
> +    /*
> +     * Iterate all featuers to write different value (not same as MSR) for
> +     * each feature.
> +     */
> +    for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
>      {
> -        if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
> +        struct feat_node *feat = info->features[i];
> +        const struct feat_props *props = feat_props[i];
> +        unsigned int cos_num, j;
> +
> +        if ( !feat || !props )
> +            continue;
> +
> +        cos_num = props->cos_num;
> +        if ( info->array_len < index + cos_num )
> +            return;

So that you can return -ENOSPC here (inline with what was previously
done in write_psr_msrs)?

> +
> +        for ( j = 0; j < cos_num; j++ )
>          {
> -            feat->cos_reg_val[cos * cos_num + i] = info->val[i];
> -            props->write_msr(cos, info->val[i], props->type[i]);
> +            if ( feat->cos_reg_val[cos * cos_num + j] != info->val[index + j] )
> +            {
> +                feat->cos_reg_val[cos * cos_num + j] = info->val[index + j];
> +                props->write_msr(cos, info->val[index + j], props->type[j]);
> +            }
>          }
> +
> +        index += cos_num;
>      }
>  }
>  
> @@ -1137,30 +1155,18 @@ static int write_psr_msrs(unsigned int socket, unsigned int cos,
>                            const uint32_t val[], unsigned int array_len,
>                            enum psr_feat_type feat_type)
>  {
> -    int ret;
>      struct psr_socket_info *info = get_socket_info(socket);
>      struct cos_write_info data =
>      {
>          .cos = cos,
> -        .feature = info->features[feat_type],
> -        .props = feat_props[feat_type],
> +        .features = info->features,
> +        .val = val,
> +        .array_len = array_len,
>      };
>  
>      if ( cos > info->features[feat_type]->cos_max )
>          return -EINVAL;
>  
> -    /* Skip to the feature's value head. */
> -    ret = skip_prior_features(&array_len, feat_type);
> -    if ( ret < 0 )
> -        return ret;
> -
> -    val += ret;
> -
> -    if ( array_len < feat_props[feat_type]->cos_num )

When moved inside of do_write_psr_msrs this becomes:

info->array_len < index + cos_num

Where cos_num == feat_props[feat_type]->cos_num. Is this correct?

I'm asking because the check used to be array_len < cos_num.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-10-09 14:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06  9:13 [PATCH v1] x86: psr: support co-exist features' values setting Yi Sun
2017-10-06 14:38 ` Roger Pau Monné
2017-10-08  2:14   ` Yi Sun
2017-10-08  4:22 ` [PATCH v2] " Yi Sun
2017-10-09 14:03   ` Roger Pau Monné [this message]
2017-10-10  0:41     ` Yi Sun
2017-10-10  8:22       ` Roger Pau Monné
2017-10-10  9:19 ` [PATCH v3] " Yi Sun
2017-10-10  9:49   ` Roger Pau Monné
2017-10-10 14:44   ` Jan Beulich
2017-10-11  1:55 ` [PATCH v4] " Yi Sun
2017-10-11  6:59   ` Chao Peng
2017-10-11  7:14     ` Yi Sun
2017-10-11  7:20 ` [PATCH v5] " Yi Sun
2017-10-11 12:06   ` Jan Beulich
2017-10-12  2:52     ` Yi Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171009140325.nex4ernpmra5brxz@dhcp-3-128.uk.xensource.com \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yi.y.sun@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.