Re: [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross <jgross@suse.com>]

On 14/04/16 19:07, Ian Jackson wrote:
> This is my attempt at understanding the situation, from reading
> descriptions provided on list in the context of toolstack patches
> which were attempting to work around the anomaly.
> 
> The multiple `xxx' entries reflect 1. my lack of complete understanding
> 2. API defects which I think I have identified.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> CC: Dario Faggioli <dario.faggioli@citrix.com>
> CC: Juergen Gross <jgross@suse.com>
> CC: George Dunlap <george.dunlap@eu.citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/include/public/sysctl.h |   28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 0849908..cfccf38 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -560,6 +560,34 @@ 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);
>  
> +/*
> + * cpupool operations may return EBUSY if the operation cannot be
> + * executed right now because of another cpupool operation which is
> + * still in progress.  In this case, EBUSY means that the failed
> + * operation had no effect.
> + *
> + * Some operations including at least RMCPU (xxx which others?) may

Only this one.

> + * also return EBUSY because a guest has temporarily pinned one of its
> + * vcpus to the pcpu in question.  It is the pious hope (xxx) of the
> + * author of this comment that this can only occur for domains which
> + * have been granted some kind of hardware privilege (eg passthrough).

Only the hardware domain is allowed to do this.

> + * In this case the operation 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.  (xxx is this true?)

Yes.

> + *
> + * This can be detected by seeing whether the pcpu can be added to a
> + * different cpupool.  (xxx this is a silly interface; the situation
> + * should be reported by a different errno value, at least.)  If the

I'm open for suggestions. :-)

> + * pcpu can't be added to a different cpupool for this reason,
> + * attempts to do so will returning (xxx what errno value?)

You might have guessed: EBUSY

> + *
> + * The anomalous situation can be recovered by adding the pcpu back to
> + * the cpupool it came from (xxx this permits a buggy or malicious
> + * guest to prevent the cpu ever being removed from its cpupool).

Only the hardware domain, which has other means to inject problems.


Juergen

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