[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 12/25] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.
>>> On 30.03.17 at 03:37, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: > On 17-03-29 03:57:52, Jan Beulich wrote: >> >>> 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. >> > Then, I think I have to reuse the 'type'. As only CDP needs type to decide > which value to be returned so far, I think I can implement codes like below > to make CDP can handle all scenarios. > > static void l3_cdp_get_val(const struct feat_node *feat, unsigned int cos, > enum cbm_type type, uint32_t *val) > { > if ( type == PSR_CBM_TYPE_L3_DATA || flag == 0xF000 ) > *val = get_cdp_data(feat, cos); > if ( type == PSR_CBM_TYPE_L3_CODE || flag == 0xF001 ) > *val = get_cdp_code(feat, cos); > } > > static bool fits_cos_max(...) > { > ...... > for (i = 0; i < feat->props->cos_num; i++) > { > feat->props->get_val(feat, cos, i + 0xF000, &default_val); > if ( val[i] == default_val ) > ...... > } > ...... > } > > Is that good for you? Urgh - no, not really: This is hackery. Do you have a tree somewhere so I could look at the file after at least the CDP patches have all been applied, to see whether I have a better idea? Alternatively, could you attach psr.c the way you have it right now with the entire series applied? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |