From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Pausing / unpausing a single domain VCPU via libxc Date: Thu, 26 Jan 2017 17:00:18 +0100 Message-ID: <1485446418.32103.176.camel@citrix.com> References: <1485443658.32103.165.camel@citrix.com> <02a42e84-dded-f681-d3fb-681402177c09@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5944153322484554643==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWmTW-0005QA-GZ for xen-devel@lists.xenproject.org; Thu, 26 Jan 2017 16:00:38 +0000 In-Reply-To: <02a42e84-dded-f681-d3fb-681402177c09@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Razvan Cojocaru , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Ian Jackson , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============5944153322484554643== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-1JOp42HI51anUUzjlPCg" --=-1JOp42HI51anUUzjlPCg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-01-26 at 17:42 +0200, Razvan Cojocaru wrote: > On 01/26/2017 05:14 PM, Dario Faggioli wrote: > > You mean you'd want to implement xc_vcpu_pause() by means of > > the XEN_DOMCTL_gdbsx_pausevcpu? > >=20 > > What's the use case for that, and does it fit with the > > implementation > > of said hypercall (which, e.g., requires that the domain is already > > paused)? >=20 > Not necessarily implement xc_vcpu_pause() by means of > XEN_DOMCTL_gdbsx_pausevcpu, it's just that from a design perspective > this seems rather specialised - the domctl name suggests that this is > only useful for debugging, and it also hardcodes an implementation > for > calling that hypercall in xg_main.c, whereas pausing a single VCPU is > a > generic operation that other clients, as well as the debugger, might > find worthwhile to do. >=20 And, in principle, I agree that it would make sense to have a generic vCPU pause/unpause API. Outside of principle --a.k.a., in practise-- I'm not sure whether it really makes sense, and whether it would actually work. I'm thinking of how happy a guest would be to be running with one of it's (v)CPU frozen, and am wondering whether this could cause it to panic, or behave funnily. But I haven't tried, of course. > Does XEN_DOMCTL_gdbsx_pausevcpu require that the whole domain is > paused > (for longer that the duration of the actual hypercall)? >=20 AFAICT, it does. See the implementation of the hypercall: if ( !d->controller_pause_count ) break; ret =3D -EINVAL; if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >=3D d->max_vcpus || (v =3D d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) =3D=3D NUL= L ) break; ret =3D vcpu_pause_by_systemcontroller(v); See commit 680d79f10 ("x86/gdbsx: invert preconditions for XEN_DOMCTL_gdbsx_{,un}pausevcpu hypercalls": Revert back to how it was originally, i.e. the XEN_DOMCTL_gdbsx_{,un}pa= usevcpu hypercalls are only valid for a domain already paused by the system con= troller. And see how it's used, e.g., as described in the comment above xg_step() (or even in its actual code): /* * Single step the given vcpu. This is achieved by pausing all but given vc= pus, * setting the TF flag, let the domain run and pause, unpause all vcpus, an= d * clear TF flag on given vcpu. * Returns: 0 success */ Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-1JOp42HI51anUUzjlPCg 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 iQIcBAABCAAGBQJYih0SAAoJEBZCeImluHPu3bwQAIxCm6LNTGvP4FA/9BJVZGLG jbv0/iVW+CWe7ajt3fyuDNSupWDx6M8FBKQ4mbFqLT6Xoe9dyP7sjZwdllj9yRL1 WAF8yBX2YJGqDPJ5t4Ei6PdLMV4Yf8tNpiCkL0mLBL1klsGPIlsY17BEj9dARQKF 7b3K2v5vUQOXOYCm5qcSy4/4/mPBKCZjPQ3mW9WyWabyZhF+Cjb6W2xyhzp0j7vd glv8ZRLKBN6BiMHpm082VOFowEQKtm9ZODIpIdQ3Z4JtG67qV53Wzmc0YJgK437p ymPP/nFD8nzXhJ8O+IudS690SWiW28vtwVy2n4/2A7tT1reIEbyVPW5c7bN2m8a6 Qb93vU2MiB9bmpDAzjEUWIdhOU6aT0MHn+D1NwgX4k+553MovDmkAl7RtZ3FmYBE jQqh5QErsfGWD811UBhxrd0241p+e6XN42nLEUILqgzHXJ9twNtFfKLaLAXAum5n r34VjIWiuJ3nnskGRjcewx+rkAxQplYR5eK6zz4Naw/q7sHYKYO5+DiLAJEbSoue xtz2eDhH8p1E4LTCQWv79WdnlROkywFITXHrwN9TlZO9vkl4neXKUdEoSiYL30bl BxXncaQN55txXqJCtzo+fdXrQAYU+UKY7QUPyBp2E4dBUBAzRW6ksTRXwc03dzCn 4aZ+jThH7xedd+3orPLy =BJhq -----END PGP SIGNATURE----- --=-1JOp42HI51anUUzjlPCg-- --===============5944153322484554643== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5944153322484554643==--