From: "Jan Beulich" <JBeulich@suse.com>
To: Chong Li <lichong659@gmail.com>
Cc: Chong Li <chong.li@wustl.edu>, Sisu Xi <xisisu@gmail.com>,
george.dunlap@eu.citrix.com, dario.faggioli@citrix.com,
xen-devel@lists.xen.org, Meng Xu <mengxu@cis.upenn.edu>,
dgolomb@seas.upenn.edu
Subject: Re: [PATCH v4 for Xen 4.6 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler
Date: Mon, 13 Jul 2015 09:37:04 +0100 [thread overview]
Message-ID: <55A394D0020000780008FFC3@mail.emea.novell.com> (raw)
In-Reply-To: <1436590356-3706-2-git-send-email-chong.li@wustl.edu>
>>> On 11.07.15 at 06:52, <lichong659@gmail.com> wrote:
> @@ -1162,8 +1176,82 @@ rt_dom_cntl(
> }
> spin_unlock_irqrestore(&prv->lock, flags);
> break;
> + case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
> + spin_lock_irqsave(&prv->lock, flags);
> + for ( index = 0; index < op->u.v.nr_vcpus; index++ )
> + {
> + if ( copy_from_guest_offset(&local_sched,
> + op->u.v.vcpus, index, 1) )
> + {
> + rc = -EFAULT;
> + break;
> + }
> + if ( local_sched.vcpuid >= d->max_vcpus ||
> + d->vcpu[local_sched.vcpuid] == NULL )
> + {
> + rc = -EINVAL;
> + break;
> + }
> + svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> +
> + local_sched.s.rtds.budget = svc->budget / MICROSECS(1);
> + local_sched.s.rtds.period = svc->period / MICROSECS(1);
> +
> + if ( __copy_to_guest_offset(op->u.v.vcpus, index,
> + &local_sched, 1) )
> + {
> + rc = -EFAULT;
> + break;
> + }
> + if( hypercall_preempt_check() )
> + {
> + rc = -ERESTART;
> + break;
> + }
I still don't see how this is supposed to work.
> + }
> + spin_unlock_irqrestore(&prv->lock, flags);
> + break;
> + case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
> + spin_lock_irqsave(&prv->lock, flags);
> + for( index = 0; index < op->u.v.nr_vcpus; index++ )
> + {
> + if ( copy_from_guest_offset(&local_sched,
> + op->u.v.vcpus, index, 1) )
> + {
> + rc = -EFAULT;
> + break;
> + }
> + if ( local_sched.vcpuid >= d->max_vcpus ||
> + d->vcpu[local_sched.vcpuid] == NULL )
> + {
> + rc = -EINVAL;
> + break;
> + }
> + svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> + period = MICROSECS(local_sched.s.rtds.period);
> + budget = MICROSECS(local_sched.s.rtds.budget);
> + if ( period < MICROSECS(10) || period > RTDS_MAX_PERIOD ||
> + budget < MICROSECS(10) || budget > period )
Apart from numerous coding style issues I think the first of the
checks in this if() is redundant (covered by the combination of
the last two ones) and hence would better be dropped.
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1052,10 +1052,22 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
> if ( ret )
> return ret;
>
> - if ( (op->sched_id != DOM2OP(d)->sched_id) ||
> - ((op->cmd != XEN_DOMCTL_SCHEDOP_putinfo) &&
> - (op->cmd != XEN_DOMCTL_SCHEDOP_getinfo)) )
> + if ( op->sched_id != DOM2OP(d)->sched_id )
> return -EINVAL;
> + else
> + switch ( op->cmd )
> + {
> + case XEN_DOMCTL_SCHEDOP_putinfo:
> + break;
> + case XEN_DOMCTL_SCHEDOP_getinfo:
> + break;
> + case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
> + break;
> + case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
> + break;
Only this break should stay, the three earlier ones should be dropped
as redundant.
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -330,31 +330,56 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t);
> #define XEN_SCHEDULER_ARINC653 7
> #define XEN_SCHEDULER_RTDS 8
>
> +typedef struct xen_domctl_sched_sedf {
> + uint64_aligned_t period;
> + uint64_aligned_t slice;
> + uint64_aligned_t latency;
> + uint32_t extratime;
> + uint32_t weight;
> +} xen_domctl_sched_sedf_t;
> +
> +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;
> + } s;
> + uint16_t vcpuid;
> + uint16_t padding;
This pads to a 32-bit boundary, leaving another 32-bit hole.
> +} xen_domctl_schedparam_vcpu_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_schedparam_vcpu_t);
> +
> /* Set or get info? */
> #define XEN_DOMCTL_SCHEDOP_putinfo 0
> #define XEN_DOMCTL_SCHEDOP_getinfo 1
> +#define XEN_DOMCTL_SCHEDOP_putvcpuinfo 2
> +#define XEN_DOMCTL_SCHEDOP_getvcpuinfo 3
> struct xen_domctl_scheduler_op {
> uint32_t sched_id; /* XEN_SCHEDULER_* */
> uint32_t cmd; /* XEN_DOMCTL_SCHEDOP_* */
> union {
> - struct xen_domctl_sched_sedf {
> - uint64_aligned_t period;
> - uint64_aligned_t slice;
> - uint64_aligned_t latency;
> - uint32_t extratime;
> - uint32_t weight;
> - } sedf;
> - struct xen_domctl_sched_credit {
> - uint16_t weight;
> - uint16_t cap;
> - } credit;
> - struct xen_domctl_sched_credit2 {
> - uint16_t weight;
> - } credit2;
> - struct xen_domctl_sched_rtds {
> - uint32_t period;
> - uint32_t budget;
> - } rtds;
> + xen_domctl_sched_sedf_t sedf;
> + xen_domctl_sched_credit_t credit;
> + xen_domctl_sched_credit2_t credit2;
> + xen_domctl_sched_rtds_t rtds;
> + struct {
> + XEN_GUEST_HANDLE_64(xen_domctl_schedparam_vcpu_t) vcpus;
> + uint16_t nr_vcpus;
> + } v;
And there's still no explicit padding here at all (nor am I convinced
that uint16_t is really a good choice for nr_vcpus - uint32_t would
seem more natural without causing any problems or structure
growth).
Jan
next prev parent reply other threads:[~2015-07-13 8:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 4:52 [PATCH v4 for Xen 4.6 0/4] Enable per-VCPU parameter settings for RTDS scheduler Chong Li
2015-07-11 4:52 ` [PATCH v4 for Xen 4.6 1/4] xen: enable " Chong Li
2015-07-13 8:37 ` Jan Beulich [this message]
2015-08-09 15:45 ` Chong Li
2015-08-11 9:39 ` Jan Beulich
2015-07-27 15:51 ` Dario Faggioli
2015-08-09 16:08 ` Chong Li
2015-07-11 4:52 ` [PATCH v4 for Xen 4.6 2/4] libxc: " Chong Li
2015-07-27 16:11 ` Dario Faggioli
2015-08-07 16:35 ` Chong Li
2015-07-11 4:52 ` [PATCH v4 for Xen 4.6 3/4] libxl: " Chong Li
2015-07-28 9:15 ` Dario Faggioli
2015-08-07 17:34 ` Chong Li
2015-07-11 4:52 ` [PATCH v4 for Xen 4.6 4/4] xl: " Chong Li
2015-07-28 9:25 ` Dario Faggioli
2015-08-09 14:53 ` Chong Li
2015-07-11 14:33 ` [PATCH v4 for Xen 4.6 0/4] Enable " Wei Liu
2015-07-13 10:27 ` Dario Faggioli
2015-07-14 5:45 ` Meng Xu
2015-07-14 7:13 ` Dario Faggioli
2015-07-27 15:14 ` Dario Faggioli
2015-08-07 15:50 ` Chong Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A394D0020000780008FFC3@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=chong.li@wustl.edu \
--cc=dario.faggioli@citrix.com \
--cc=dgolomb@seas.upenn.edu \
--cc=george.dunlap@eu.citrix.com \
--cc=lichong659@gmail.com \
--cc=mengxu@cis.upenn.edu \
--cc=xen-devel@lists.xen.org \
--cc=xisisu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.