|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 02/15] Rename PSR sysctl/domctl interfaces and xsm policy to make them be general
On 17-09-25 17:15:21, Roger Pau Monn� wrote:
> On Sat, Sep 23, 2017 at 09:48:11AM +0000, Yi Sun wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
[...]
> > - case XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA:
> > - ret = psr_get_val(d, domctl->u.psr_cat_op.target,
> > + case XEN_DOMCTL_PSR_GET_L3_DATA:
> > + ret = psr_get_val(d, domctl->u.psr_alloc.target,
> > &val32, PSR_CBM_TYPE_L3_DATA);
> > - domctl->u.psr_cat_op.data = val32;
> > + domctl->u.psr_alloc.data = val32;
> > copyback = true;
> > break;
> >
> > - case XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM:
> > - ret = psr_get_val(d, domctl->u.psr_cat_op.target,
> > + case XEN_DOMCTL_PSR_GET_L2_CBM:
> > + ret = psr_get_val(d, domctl->u.psr_alloc.target,
> > &val32, PSR_CBM_TYPE_L2);
> > - domctl->u.psr_cat_op.data = val32;
> > + domctl->u.psr_alloc.data = val32;
> > copyback = true;
>
> This:
>
> ret = psr_get_val(...);
> domctl->u.psr...;
> copyback = true;
>
> Construct is quite repetitive, maybe you could consider adding a local
> macro to hide it?
>
> Maybe then you could also hide the val32 declaration inside of it.
>
Thanks for the suggestion! Let me try.
[...]
> >
> > --- a/xen/arch/x86/sysctl.c
> > +++ b/xen/arch/x86/sysctl.c
> > @@ -171,45 +171,45 @@ long arch_do_sysctl(
> >
> > break;
> >
> > - case XEN_SYSCTL_psr_cat_op:
> > - switch ( sysctl->u.psr_cat_op.cmd )
> > + case XEN_SYSCTL_psr_alloc:
> > + switch ( sysctl->u.psr_alloc.cmd )
> > {
> > uint32_t data[PSR_INFO_ARRAY_SIZE];
> >
> > - case XEN_SYSCTL_PSR_CAT_get_l3_info:
> > + case XEN_SYSCTL_PSR_get_l3_info:
> > {
> > - ret = psr_get_info(sysctl->u.psr_cat_op.target,
> > + ret = psr_get_info(sysctl->u.psr_alloc.target,
> > PSR_CBM_TYPE_L3, data, ARRAY_SIZE(data));
> > if ( ret )
> > break;
> >
> > - sysctl->u.psr_cat_op.u.cat_info.cos_max =
> > + sysctl->u.psr_alloc.u.cat_info.cos_max =
> > data[PSR_INFO_IDX_COS_MAX];
> > - sysctl->u.psr_cat_op.u.cat_info.cbm_len =
> > + sysctl->u.psr_alloc.u.cat_info.cbm_len =
> > data[PSR_INFO_IDX_CAT_CBM_LEN];
> > - sysctl->u.psr_cat_op.u.cat_info.flags =
> > + sysctl->u.psr_alloc.u.cat_info.flags =
> > data[PSR_INFO_IDX_CAT_FLAG];
> >
> > - if ( __copy_field_to_guest(u_sysctl, sysctl, u.psr_cat_op) )
> > + if ( __copy_field_to_guest(u_sysctl, sysctl, u.psr_alloc) )
> > ret = -EFAULT;
> > break;
> > }
> >
> > - case XEN_SYSCTL_PSR_CAT_get_l2_info:
> > + case XEN_SYSCTL_PSR_get_l2_info:
> > {
> > - ret = psr_get_info(sysctl->u.psr_cat_op.target,
> > + ret = psr_get_info(sysctl->u.psr_alloc.target,
> > PSR_CBM_TYPE_L2, data, ARRAY_SIZE(data));
> > if ( ret )
> > break;
> >
> > - sysctl->u.psr_cat_op.u.cat_info.cos_max =
> > + sysctl->u.psr_alloc.u.cat_info.cos_max =
> > data[PSR_INFO_IDX_COS_MAX];
> > - sysctl->u.psr_cat_op.u.cat_info.cbm_len =
> > + sysctl->u.psr_alloc.u.cat_info.cbm_len =
> > data[PSR_INFO_IDX_CAT_CBM_LEN];
> > - sysctl->u.psr_cat_op.u.cat_info.flags =
> > + sysctl->u.psr_alloc.u.cat_info.flags =
> > data[PSR_INFO_IDX_CAT_FLAG];
>
> The above repetition is also unneeded AFAICT. Why not simplify the
> switch to:
>
> uint32_t data[PSR_INFO_ARRAY_SIZE];
> enum cbm_type type;
>
> switch ( sysctl->u.psr_alloc.cmd )
> {
> case XEN_SYSCTL_PSR_get_l3_info:
> type = PSR_CBM_TYPE_L3;
> break;
> case XEN_SYSCTL_PSR_get_l2_info:
> type = PSR_CBM_TYPE_L2;
> break;
> default:
> return -EOPNOTSUPP;
> }
>
> ret = psr_get_info(sysctl->u.psr_alloc.target, type, data, ARRAY_SIZE(data));
> if ( ret )
> break;
>
> sysctl->u.psr_alloc.u.cat_info.cos_max = data[PSR_INFO_IDX_COS_MAX];
> ...
>
> It would prevent some of this code repetition IMHO.
>
Thank you! But this way seems only good to CAT features but could not cover MBA.
Although I can assign "type = PSR_TYPE_MBA_THRTL" for MBA, the assignment of
'sysctl->u.psr_alloc.u.mba_info' and 'sysctl->u.psr_alloc.u.cat_info' cannot be
converged. We have to check the type to decide to assign value to which 'info'.
> Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |