From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result Date: Thu, 14 Apr 2016 22:22:10 +0200 Message-ID: <1460665330.13871.196.camel@citrix.com> References: <1460653660-6654-1-git-send-email-ian.jackson@eu.citrix.com> <1460653660-6654-4-git-send-email-ian.jackson@eu.citrix.com> <570FD25B.3060802@citrix.com> <22287.55772.931614.61945@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7721640132062302919==" Return-path: In-Reply-To: <22287.55772.931614.61945@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Ian Jackson , Andrew Cooper Cc: Juergen Gross , xen-devel@lists.xensource.com, Wei Liu , George Dunlap , Tim Deegan , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============7721640132062302919== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aoJlBtCZK5o9d+JukdPG" --=-aoJlBtCZK5o9d+JukdPG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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"): > >=20 > > On 14/04/16 18:07, Ian Jackson wrote: > > >=20 > > > +/* > > > + * cpupool operations may return EBUSY if the operation cannot > > > be > > > + * executed right now because of another cpupool operation which > > > is > > > + * still in progress.=C2=A0=C2=A0In 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.=C2=A0=C2=A0It is the pious hope (x= xx) 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.=C2=A0 > > Any arbitrary pinning can be applied at runtime via `xl vcpu-pin > > ...` > Does that produce EBUSY as well ? >=20 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 >=20 > =C2=A0 "the existing configuration (eg toolstack-selected vcpu pinning) > =C2=A0=C2=A0=C2=A0means that the operation does not make sense" >=20 This return -EINVAL. > =C2=A0 "there is some lock contention and trying again may help" >=20 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). > =C2=A0 "a semantically conflicting, or nearly-semantically-conflicting, > =C2=A0=C2=A0=C2=A0operation is currently in progress" >=20 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. > =C2=A0 "the guest has done a temporary pin which prevents this operation" >=20 This (because of the series) returns -EBUSY. > is very unfortunate.=C2=A0=C2=A0How is a toolstack to know what to do ? >=20 Yeah, I agree, but again, I think in this case it's possible for toolstack to tell. =46rom 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.=C2=A0=C2=A0(i.e. the host admin has to choose the pinning.) > AIUI, that is not (now) true. >=20 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: =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D -EPERM; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if ( !is_hardware_domain(cu= rrent->domain) ) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0bre= ak; which I think satisfies Ian's (legitimate) concern? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-aoJlBtCZK5o9d+JukdPG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlcP+/IACgkQk4XaBE3IOsScIgCeKZyMF+ns7FeQXXRNdZtDQ9jh unUAn3jtDK2OXK49DrWe81kaIgALk6OK =jWuS -----END PGP SIGNATURE----- --=-aoJlBtCZK5o9d+JukdPG-- --===============7721640132062302919== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============7721640132062302919==--