Re: [Xen-devel] [PATCH v4 05/24] x86: refactor psr: implement Domain init/free and schedule flows.

[Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx>]

On 17-01-10 06:34:50, Jan Beulich wrote:
> >>> On 14.12.16 at 05:07, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> > @@ -358,11 +366,32 @@ void psr_free_rmid(struct domain *d)
> >      d->arch.psr_rmid = 0;
> >  }
> >  
> > +static inline unsigned int get_max_cos_max(const struct psr_socket_info 
> > *info)
> > +{
> > +    const struct feat_node *feat_tmp;
> 
> Same remark as on the earlier patch regarding the _tmp suffix.
> Should this reoccur in later patches, I won't give the same
> comment again.
> 
Thank you! I will take care all of them.

> > +    unsigned int cos_max = 0;
> > +
> > +    list_for_each_entry(feat_tmp, &info->feat_list, list)
> > +        cos_max = max(feat_tmp->ops.get_max_cos_max(feat_tmp), cos_max);
> > +
> > +    return cos_max;
> > +}
> > +
> >  static inline void psr_assoc_init(void)
> >  {
> >      struct psr_assoc *psra = &this_cpu(psr_assoc);
> >  
> > -    if ( psr_cmt_enabled() )
> > +    if ( socket_info )
> > +    {
> > +        unsigned int socket = cpu_to_socket(smp_processor_id());
> > +        const struct psr_socket_info *info = socket_info + socket;
> > +        unsigned int cos_max = get_max_cos_max(info);
> > +
> > +        if ( info->feat_mask )
> > +            psra->cos_mask = ((1ull << get_count_order(cos_max)) - 1) << 
> > 32;
> > +    }
> > +
> > +    if ( psr_cmt_enabled() || psra->cos_mask )
> >          rdmsrl(MSR_IA32_PSR_ASSOC, psra->val);
> >  }
> >  
> > @@ -371,6 +400,12 @@ static inline void psr_assoc_rmid(uint64_t *reg, 
> > unsigned int rmid)
> >      *reg = (*reg & ~rmid_mask) | (rmid & rmid_mask);
> >  }
> >  
> > +static inline void psr_assoc_cos(uint64_t *reg, unsigned int cos,
> > +                                 uint64_t cos_mask)
> > +{
> > +    *reg = (*reg & ~cos_mask) | (((uint64_t)cos << 32) & cos_mask);
> 
> This recurring 32 would perhaps better become a #define, so they
> can be identified as the same entity (at least I think they are).
> 
Good suggestion, thanks!

> Jan

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