Re: [Xen-devel] [PATCH 3/4] tools/libxc: Alow getting and setting the max sub C-State

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.06.14 at 17:04, <ross.lagerwall@xxxxxxxxxx> wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -366,6 +366,10 @@ struct xen_sysctl_pm_op {
>      #define XEN_SYSCTL_pm_op_enable_turbo               0x26
>      #define XEN_SYSCTL_pm_op_disable_turbo              0x27
>  
> +    /* cpuidle max_substate access command */
> +    #define XEN_SYSCTL_pm_op_get_max_substate     0x28
> +    #define XEN_SYSCTL_pm_op_set_max_substate     0x29
> +
>      uint32_t cmd;
>      uint32_t cpuid;
>      union {
> @@ -376,6 +380,8 @@ struct xen_sysctl_pm_op {
>          uint32_t                    set_sched_opt_smt;
>          uint32_t                    get_max_cstate;
>          uint32_t                    set_max_cstate;
> +        uint32_t                    get_max_substate;
> +        uint32_t                    set_max_substate;
>          uint32_t                    get_vcpu_migration_delay;
>          uint32_t                    set_vcpu_migration_delay;
>      } u;

I'm really uncertain about adding whole new sub-ops and union fields
for this. For simplicity's sake I'd simply re-use the ops and fields we
already have (with cpuid, which is unused anyway, distinguishing
between main and sub-states).

But then again now that I look at this from an interface perspective
I wonder whether sooner or later we wouldn't want to be able to
specify maximum sub-states per main state. That surely would
require separate new sub-ops (as it would likely require handles to
be passed in).

Jan


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