Re: [PATCH v9 12/25] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

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

On 17-03-29 09:20:21, Yi Sun wrote:
> On 17-03-28 06:20:48, Jan Beulich wrote:
> > >>> On 28.03.17 at 13:59, <yi.y.sun@linux.intel.com> wrote:
> > > I think we at least need a 'get_val()' hook.
> > 
> > Of course.
> > 
> > > I try to implement CAT/CDP hook.
> > > Please help to check if this is what you thought.
> > 
> > One remark below, but other than that - yes.
> > 
> > > static void cat_get_val(const struct feat_node *feat, unsigned int cos,
> > >                         enum cbm_type type, int flag, uint32_t *val)
> > > {
> > >     *val = feat->cos_reg_val[cos];
> > > }
> > > 
> > > static void l3_cdp_get_val(const struct feat_node *feat, unsigned int cos,
> > >                            enum cbm_type type, int flag, uint32_t *val)
> > > {
> > >     if ( type == PSR_CBM_TYPE_L3_DATA || flag == 0 )
> > >         *val = get_cdp_data(feat, cos);
> > >     if ( type == PSR_CBM_TYPE_L3_CODE || flag == 1 )
> > >         *val = get_cdp_code(feat, cos);
> > > }
> > 
> > Why the redundancy between type and flag?
> > 
> For psr_get_val, upper layer input the cbm_type to get either DATA or CODE
> value. For other cases, we use flag as cos_num index to get either DATA or
> CODE.
> 
Let me explain more to avoid confusion. For other cases, we use cos_num as
index to get values from a feature. In these cases, we do not know the
cbm_type of the feature. So, I use the cos_num as flag to make 'get_val'
know which value should be returned.

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

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