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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.17 at 03:36, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx> 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.

I'm pretty sure this redundancy can be avoided.

Jan


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