| Message ID | 1460732057-30032-4-git-send-email-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes"):
> Requested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Thanks this is very helpful. I think it should go in as soon as the
actual hypervisor code side has the appropriate ack.
But I have some suggestions for enhancement:
> +/*
> + * Error return values of cpupool operations:
> + *
> + * -EADDRINUSE:
> + * XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu
> + * which is to be removed from a cpupool.
I think this ought to mention the anomalous state the pcpu is left in,
and advise what should be done about it. I think it would be helpful
to crib from my earlier xxx-ful text. How about:
In this case RMCPU may have been partially carried out and the pcpu
is left in an anomalous state. In this state the pcpu may be used
by some not readily predictable subset of the vcpus (domains) whose
vcpus are in the old cpupool.
> The anomalous situation can be recovered by adding the pcpu back to
> the cpupool it came from, and then retrying the RMCPU.
But I notice that the code you propose for libxc doesn't do the
re-add: it just retries the remove. So either the text above (which
you and Dario seemed to agree with) is wrong, or the libxc code is
wrong.
And, perhaps we ought to mention here that this temporary pinning can
only be done by the hardware domain ? Or at least refer to the
temporary pin operation.
Ian.
On 15/04/16 17:25, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes"): >> Requested-by: Ian Jackson <Ian.Jackson@eu.citrix.com> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > > Thanks this is very helpful. I think it should go in as soon as the > actual hypervisor code side has the appropriate ack. > > But I have some suggestions for enhancement: > >> +/* >> + * Error return values of cpupool operations: >> + * >> + * -EADDRINUSE: >> + * XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu >> + * which is to be removed from a cpupool. > > I think this ought to mention the anomalous state the pcpu is left in, > and advise what should be done about it. I think it would be helpful > to crib from my earlier xxx-ful text. How about: > > In this case RMCPU may have been partially carried out and the pcpu > is left in an anomalous state. In this state the pcpu may be used > by some not readily predictable subset of the vcpus (domains) whose > vcpus are in the old cpupool. > >> The anomalous situation can be recovered by adding the pcpu back to >> the cpupool it came from, and then retrying the RMCPU. > > But I notice that the code you propose for libxc doesn't do the > re-add: it just retries the remove. So either the text above (which > you and Dario seemed to agree with) is wrong, or the libxc code is > wrong. Re-adding it not necessary. A retry is all that is needed. In case retries don't succeed for a long time either re-adding the cpu to it's original pool or doing a "xl vcpu-pin -f ..." and a retry should clean up the situation. > And, perhaps we ought to mention here that this temporary pinning can > only be done by the hardware domain ? Or at least refer to the > temporary pin operation. Yes, together with the vcpu-pin -f hint. I think this can wait until next week. Juergen
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index 4596d20..82a2a3e 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -559,6 +559,42 @@ struct xen_sysctl_cpupool_op { typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t; DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t); +/* + * Error return values of cpupool operations: + * + * -EADDRINUSE: + * XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu + * which is to be removed from a cpupool. + * -EADDRNOTAVAIL: + * XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: A previous + * request to remove a cpu from a cpupool was terminated with -EAGAIN + * and has not been retried using the same parameters. + * -EAGAIN: + * XEN_SYSCTL_CPUPOOL_OP_RMCPU: The cpu can't be removed from the cpupool + * as it is active in the hypervisor. A retry will succeed soon. + * -EBUSY: + * XEN_SYSCTL_CPUPOOL_OP_DESTROY, XEN_SYSCTL_CPUPOOL_OP_RMCPU: A cpupool + * can't be destroyed or the last cpu can't be removed as there is still + * a running domain in that cpupool. + * -EEXIST: + * XEN_SYSCTL_CPUPOOL_OP_CREATE: A cpupool_id was specified and is already + * existing. + * -EINVAL: + * XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: An illegal + * cpu was specified (cpu does not exist). + * XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN: An illegal domain was specified + * (domain id illegal or not suitable for operation). + * -ENODEV: + * XEN_SYSCTL_CPUPOOL_OP_ADDCPU, XEN_SYSCTL_CPUPOOL_OP_RMCPU: The specified + * cpu is either not free (add) or not member of the specified cpupool + * (remove). + * -ENOENT: + * all: The cpupool with the specified cpupool_id doesn't exist. + * + * Some common error return values like -ENOMEM and -EFAULT are possible for + * all the operations. + */ + #define ARINC653_MAX_DOMAINS_PER_SCHEDULE 64 /* * This structure is used to pass a new ARINC653 schedule from a
Requested-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com> --- xen/include/public/sysctl.h | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)