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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2016-04-14 at 18:56 +0100, Ian Jackson wrote:
> 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 ?
> 
It can, after Juergen series, but I think in this case (setting
affinity), the situation is still acceptable. In fact:

> 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"
> 
This return -EINVAL.

>   "there is some lock contention and trying again may help"
> 
This can't happen in this case (and reason is just that setting the
affinity of a vcpu is different and less problematic than removing a
cpu from a cpupool).

>   "a semantically conflicting, or nearly-semantically-conflicting,
>    operation is currently in progress"
> 
I'm not sure what this means exactly, but I think that --depending on
what it exactly means-- it either can't happen or fall into the -EINVAL
case.

>   "the guest has done a temporary pin which prevents this operation"
> 
This (because of the series) returns -EBUSY.

> is very unfortunate.  How is a toolstack to know what to do ?
> 
Yeah, I agree, but again, I think in this case it's possible for
toolstack to tell.

From a quick check, we do not, in libxl, output any specific error
message in case we get -EBUSY... but I can send a patch to that effect
pretty quickly, if that's deemed necessary.

> > (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.
> 
Yes, now a guest can call the new SCHEDOP_pin_override hypercall (and
Juergen is pushing a series to Linux for it to be able to do that... as
that was the purpose of the while thing!).

However, as said in another email, there's already a check like this in
place, in the implementation of such an hypercall:

        ret = -EPERM;
        if ( !is_hardware_domain(current->domain) )
            break;

which I think satisfies Ian's (legitimate) concern?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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