From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] VMX: sync CPU state upon vCPU destruction Date: Fri, 10 Nov 2017 10:50:20 +0100 Message-ID: <1510307420.4517.232.camel@linux.it> References: <5A04791A020000780018D9F4@prv-mh.provo.novell.com> <1510303282.3400.1.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5517791257210386840==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eD5xH-0005NH-Vw for xen-devel@lists.xenproject.org; Fri, 10 Nov 2017 09:50:32 +0000 Received: by mail-wm0-f42.google.com with SMTP id b9so1477699wmh.5 for ; Fri, 10 Nov 2017 01:50:27 -0800 (PST) In-Reply-To: <1510303282.3400.1.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Sergey Dyasli , "JBeulich@suse.com" , "xen-devel@lists.xenproject.org" Cc: Igor Druzhinin , Kevin Tian , "julien.grall@arm.com" , "jun.nakajima@intel.com" , Andrew Cooper List-Id: xen-devel@lists.xenproject.org --===============5517791257210386840== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-lb2gJAlYr3HbQE7m5qz4" --=-lb2gJAlYr3HbQE7m5qz4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-11-10 at 08:41 +0000, Sergey Dyasli wrote: > On Thu, 2017-11-09 at 07:49 -0700, Jan Beulich wrote: > >=20 > This patch fixes only one particular issue and not the general > problem. > What if vmcs is cleared, possibly in some future code, at another > place? >=20 Yes, that's what we were saying yesterday. Asynchronous code fiddling with context, will have to make sure it syncs things properly. And we need to keep an eye out for that. > The original intent of vmx_vmcs_reload() is correct: it lazily loads > the vmcs when it's needed. It's just the logic which checks for > v->is_running inside vmx_ctxt_switch_from() is flawed: v might be > "running" on another pCPU. >=20 > IMHO there are 2 possible solutions: >=20 > 1. Add additional pCPU check into vmx_ctxt_switch_from() > How? Checking v->processor is not an option as, AFAICS, this runs without owning the scheduling lock, and hence processor can change under your feet. > 2. Drop v->is_running check inside vmx_ctxt_switch_from() making > vmx_vmcs_reload() unconditional. >=20 Well, that looks plausible to me. Although, I guess it will have, at least potentially, an impact on performance (as other solutions envisioned in the thread). Any idea how big the hit could be? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli --=-lb2gJAlYr3HbQE7m5qz4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAloFdl0ACgkQFkJ4iaW4 c+7Krg/+LngHUfagtgmo3h2iEAqu7N+MGRJos5+VpstOsL/W4ds+TqTr6IjrRkhL XjdF8JmmFbRZ4MrQP6MNHq/w+joQTqPHFpj4w4OhwLDOgGxR7qTfleT2uSeHmPS8 XLqlTx8pc08LBjlOOp1imQJyuaVifVsgJmauoLxhGGsejAPt9U6B8S3RXYf102UJ +NyidZfLwyN1GLrRPpHKToOuy//eTAAwfVSJaFXwHWC6cIjcYGAhN3Pez1xGqCi4 ZCQ+zgrgyz8upTTwh2EoYV6wSX+pr+4fRgTEmAvWTYjqL8ac2oV7YqCEi1oxkZjk UqfeYbrF2z8MDfuy6zs4NXkTIClPlHMzsSKqf7jcmWiqFgwaYUuz5Hio7FnNvV+c FU32mH2p3Gyz4AWkKZzITxeFZf6W9az8eFAGcJZFJwahoHKQBkDDHkb5bWpKTxqT MsgdmLR7MJ91bkrtK9ADTL++xyc/nyScTsFhZmTL6pWjj1WCQWQw+DXq1SKnUj64 G++gYX3NC9lqMF+PAbU8SsyOrx2+2Fzh1alo5qRp2B4zW+95bJZFnS8M5jfY1cAO 9ILueG20DUEal3u/tNeGe/qJVdYo+MXtWf+oGJsJ7e60/768AaSPaqA/iBCIGqgD yWcOyHfPIjO9q7ZFpTJI30nEAn2sOptB1bhVPq68j33Xyg79tLY= =TPrm -----END PGP SIGNATURE----- --=-lb2gJAlYr3HbQE7m5qz4-- --===============5517791257210386840== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5517791257210386840==--