Re: [PATCH v10 08/25] x86: refactor psr: L3 CAT: implement get value flow.

[Yi Sun <yi.y.sun@linux.intel.com>]

On 17-04-06 08:08:11, Jan Beulich wrote:
> >>> On 06.04.17 at 13:13, <yi.y.sun@linux.intel.com> wrote:
> > On 17-04-06 02:40:01, Jan Beulich wrote:
> >> >>> On 06.04.17 at 08:10, <yi.y.sun@linux.intel.com> wrote:
> >> > On 17-04-05 09:51:44, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53, <yi.y.sun@linux.intel.com> wrote:
> > 
> > [...]
> >> >> > --- a/xen/arch/x86/psr.c
> >> >> > +++ b/xen/arch/x86/psr.c
> >> >> > @@ -97,6 +97,10 @@ struct feat_node {
> >> >> >          /* get_feat_info is used to get feature HW info. */
> >> >> >          bool (*get_feat_info)(const struct feat_node *feat,
> >> >> >                                uint32_t data[], unsigned int array_len);
> >> >> > +
> >> >> > +        /* get_val is used to get feature COS register value. */
> >> >> > +        void (*get_val)(const struct feat_node *feat, unsigned int cos,
> >> >> > +                        uint32_t *val);
> >> >> >      } *props;
> >> >> >  
> >> >> >      uint32_t cos_reg_val[MAX_COS_REG_CNT];
> >> >> > @@ -265,10 +269,17 @@ static bool cat_get_feat_info(const struct feat_node 
> > *feat,
> >> >> >      return true;
> >> >> >  }
> >> >> >  
> >> >> > +static void cat_get_val(const struct feat_node *feat, unsigned int cos,
> >> >> > +                        uint32_t *val)
> >> >> > +{
> >> >> > +    *val = feat->cos_reg_val[cos];
> >> >> > +}
> >> >> 
> >> >> This can be done by the caller - there's nothing feature specific in
> >> >> here, so there's no need for a hook.
> >> >> 
> >> > Hmm, CDP's 'get_val' is different so that we need this hook. Do you mean I
> >> > should create this CAT's 'get_val' hook when implementing CDP patch?
> >> 
> >> No, not really - doesn't the type-to-index mapping array (or
> >> whichever way it ends up being) all take care of the feature
> >> specific aspects here?
> >>
> > For CDP case, the value getting depends on type. If we don't have this hook,
> > we have to do special handling in main flow.
> > 
> > Still use 'fits_cos_max' as example:
> >     /* For CDP, DATA is the first item in val[], CODE is the second. */
> >     for ( j = 0; j < feat->props->cos_num; j++ )                       
> >     {                                                                  
> >         feat->props->get_val(feat, 0, feat->props->type[j],            
> >                              &default_val);                          
> >         if ( val[j] != default_val )                              
> >             return false;                                       
> >     } 
> > 
> > We want to get CDP DATA and CODE one by one to compare with val[] as the 
> > order.
> > If we do not have 'get_val', how can we handle this case? Getting DATA is
> > different with getting CODE which is shown below. Even we have 
> > type-to-index,
> > we still need the hook to help I think. So far, I cannot figure out a 
> > generic
> > way.
> > Get data: (feat)->cos_reg_val[(cos) * 2]
> > Get code: (feat)->cos_reg_val[(cos) * 2 + 1]
> 
> Which makes it
> 
>     for ( i = 0; i < props->cos_num; ++i )
>         val[i] = feat->cos_reg_val[cos * props->cos_num + i];
> 
> ?
> 
Great, thanks! Then, I will remove 'get_val' hook.

BRs,
Sun Yi

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