From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 2/3] xen: add hypercall option to temporarily pin a vcpu Date: Wed, 2 Mar 2016 17:03:31 +0100 Message-ID: <1456934611.2959.371.camel@citrix.com> References: <1456822933-25041-1-git-send-email-jgross@suse.com> <1456822933-25041-3-git-send-email-jgross@suse.com> <56D5BACD.1030502@citrix.com> <56D692C3.4010509@suse.com> <1456910853.2959.286.camel@citrix.com> <56D707F7.9090506@suse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3578263839219095542==" Return-path: In-Reply-To: <56D707F7.9090506@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Juergen Gross , George Dunlap , xen-devel@lists.xen.org Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, david.vrabel@citrix.com, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org --===============3578263839219095542== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OOSgYMcWBDRxaHHjvaEn" --=-OOSgYMcWBDRxaHHjvaEn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-03-02 at 16:34 +0100, Juergen Gross wrote: > On 02/03/16 10:27, Dario Faggioli wrote: > >=C2=A0 > > However, an xl flag is easier to add, easier to document and easier > > and > > more natural to find, from the point of view of an user that really > > needs it. And perhaps it could turn out useful for other situations > > in > > future. So, I guess I'd say: > > =C2=A0- yes, let's add that > > =C2=A0- let's do it as a "force flag" of `xl vcpu-pin'. > Which raises the question: how to do that on the libxl level? >=20 Ah, right. > a) expand libxl_set_vcpuaffinity() with another parameter (is this > even > =C2=A0=C2=A0=C2=A0possible? I could do some ifdeffery, but the API would = change...) >=20 > b) add a libxl_set_vcpuaffinity_force() variant >=20 > c) imply the force flag by specifying both hard and soft maps as NULL > =C2=A0=C2=A0=C2=A0(it _is_ basically just that: keep both affinity sets),= implying > that > =C2=A0=C2=A0=C2=A0it makes no sense to specify any affinities with the -f= flag > (which > =C2=A0=C2=A0=C2=A0renders the "force" meaning rather strange, would be mo= re a > "restore" > =C2=A0=C2=A0=C2=A0now). >=20 Eheh, tools' maintainers' call. My preference would be b). I don't like a), mostly because that would mean everyone will need to specify a parameter that it is really only necessary in special cases. I could live with c), but it indeed makes the semantic too convoluted for my taste. I guess, however, that even if going for b), we need to decide whether to require a cpumask or not, and what to do if one passes NULL. Maybe we can have a cpumask parameter and, =C2=A0- if it is not NULL, force affinity to that, =C2=A0- if it is NULL, just 'restore'; what do you think? Actually, at Xen level, the override only acts on hard affinity... should libxl take only one cpumask (for hard affinity only), or both hard and soft? I'd say just one for hard is enough, unless we want to make space for a potential future situation where we will want to break and restore soft affinity as well... Dario --=C2=A0 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-OOSgYMcWBDRxaHHjvaEn 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 iEYEABECAAYFAlbXDtMACgkQk4XaBE3IOsSmUQCdFAEozdECmHF3WTNH0Ph+NgOP amkAnA4i1chbwi+dy/KVHvPUhoeKoUxs =cdVK -----END PGP SIGNATURE----- --=-OOSgYMcWBDRxaHHjvaEn-- --===============3578263839219095542== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============3578263839219095542==--