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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document 
XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
> On 14/04/16 18:07, Ian Jackson wrote:
> > +/*
> > + * 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
> > + * 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).
> 
> Any VM can be given any arbitrary pinning in its xl configuration file. 
> Any arbitrary pinning can be applied at runtime via `xl vcpu-pin ...`

Does that produce EBUSY as well ?

The reuse of the same error number for all of

  "the existing configuration (eg toolstack-selected vcpu pinning)
   means that the operation does not make sense"

  "there is some lock contention and trying again may help"

  "a semantically conflicting, or nearly-semantically-conflicting,
   operation is currently in progress"

  "the guest has done a temporary pin which prevents this operation"

is very unfortunate.  How is a toolstack to know what to do ?

> (To the best of my knowledge) A VM cannot choose pinning of its own
> accord.  (i.e. the host admin has to choose the pinning.)

AIUI, that is not (now) true.

Ian.

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