|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1] x86: psr: support co-exist features' values setting
On 17-10-06 15:38:35, Roger Pau Monn� wrote:
> On Fri, Oct 06, 2017 at 09:13: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 a same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
> ^ the
> > 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 |
> > ---------
> >
> > So, we should write all features values into their MSRs. That requires the
> > feature array, feature properties array and value array are input.
> ^ as?
>
> I'm not sure the last sentence is helpful.
>
Ok, will remove it.
> >
> > Signed-off-by: Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx>
> > ---
> > CC: Jan Beulich <jbeulich@xxxxxxxx>
> > CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> > CC: Roger Pau Monn? <roger.pau@xxxxxxxxxx>
> > CC: Julien Grall <julien.grall@xxxxxxx>
> > ---
> > xen/arch/x86/psr.c | 51 +++++++++++++++++++++++++++------------------------
> > 1 file changed, 27 insertions(+), 24 deletions(-)
> >
> > diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> > index daa2aeb..596b0ca 100644
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -1111,25 +1111,40 @@ 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)
> > {
> > 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;
> > + const uint32_t *val_array = info->val;
> >
> > - for ( i = 0; i < cos_num; i++ )
> > + 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 )
>
> Shouldn't this be '<='? index + cos_num is an index position with base
> 0 AFAICT.
>
Nope. E.g. there are L2 CAT and CDP co-exist. cos_num of L2 is 1, cos_num of CDP
is 2. CDP is the first element in feature array. array_len is 3.
1. First loop to handle CDP: index is changed from 0 to 2.
2. Second loop to handle L2:
cos_num = 1;
index + cos_num = 3;
array_len = 3;
So, we must use '<' here to check if overflow happens.
> > + return;
> > +
> > + 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] != val_array[index +
> > j] )
>
> I'm afraid this code could benefit from a comment (or comments)
> explaining what all this arrays are supposed to contain. IMHO it's not
> trivial to follow what you are trying to do here.
>
Will add comment.
> Also names like val_array are not specially helpful, it's quite clear
> that 'val_array' is an array just by looking at it's usage.
>
Ok, may consider to remove 'val_array'.
> Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |