Re: [Xen-devel] [PATCH v8 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.03.16 at 22:26, <lichong659@xxxxxxxxx> wrote:
> Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
> to independently get and set the scheduling parameters of each
> vCPU of a domain
> 
> Signed-off-by: Chong Li <chong.li@xxxxxxxxx>
> Signed-off-by: Meng Xu <mengxu@xxxxxxxxxxxxx>
> Signed-off-by: Sisu Xi <xisisu@xxxxxxxxx>
> 
> ---
> Changes on PATCH v7:
> 1) A bug in case XEN_DOMCTL_SCHEDOP_getinfo (in Xen 4.6) is fixed:
> The default PERIOD or BUDGET should be divided by MICROSECS(1),
> before returned to upper caller.

Seems like there's still some misunderstanding here: Anything
past the first --- won't make it into the repo, yet the description
of what bug you fix should end up there.

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -338,24 +338,64 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t);
>  #define XEN_SCHEDULER_ARINC653 7
>  #define XEN_SCHEDULER_RTDS     8
>  
> -/* Set or get info? */
> +typedef struct xen_domctl_sched_credit {
> +    uint16_t weight;
> +    uint16_t cap;
> +} xen_domctl_sched_credit_t;
> +
> +typedef struct xen_domctl_sched_credit2 {
> +    uint16_t weight;
> +} xen_domctl_sched_credit2_t;
> +
> +typedef struct xen_domctl_sched_rtds {
> +    uint32_t period;
> +    uint32_t budget;
> +} xen_domctl_sched_rtds_t;
> +
> +typedef struct xen_domctl_schedparam_vcpu {
> +    union {
> +        xen_domctl_sched_credit_t credit;
> +        xen_domctl_sched_credit2_t credit2;
> +        xen_domctl_sched_rtds_t rtds;
> +    } u;
> +    uint32_t vcpuid;
> +    uint16_t padding[2];

So why uint16_t[2] instead of just uint32_t? And what's the
padding needed for in the first place? Also, while for a domctl it's
not as strictly needed as for other hypercalls, checking that all
padding fields are zero would still seem to be rather desirable.

Jan


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