From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Ping: [PATCH] VMX: sync CPU state upon vCPU destruction Date: Tue, 21 Nov 2017 17:42:44 +0100 Message-ID: <1511282564.2661.27.camel@linux.it> References: <5A04791A020000780018D9F4@prv-mh.provo.novell.com> <5A1436C20200007800190868@prv-mh.provo.novell.com> <10bc9614-da0a-4007-19e6-1bd6ac909f41@citrix.com> <5A14544F02000078001909F8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0938207360114377291==" 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 1eHBdY-0000P3-Fv for xen-devel@lists.xenproject.org; Tue, 21 Nov 2017 16:43:04 +0000 Received: by mail-wm0-f45.google.com with SMTP id b189so4750263wmd.0 for ; Tue, 21 Nov 2017 08:42:55 -0800 (PST) In-Reply-To: <5A14544F02000078001909F8@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , Igor Druzhinin Cc: George Dunlap , xen-devel , Julien Grall , KevinTian , Jun Nakajima List-Id: xen-devel@lists.xenproject.org --===============0938207360114377291== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-Kqf/UjBXIhwAWggeJXNF" --=-Kqf/UjBXIhwAWggeJXNF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: > > > > On 21.11.17 at 15:07, wrote: > >=20 > The question here is: In what other cases do we expect an RCU > callback to possibly touch guest state? I think the common use is > to merely free some memory in a delayed fashion. >=20 > > Those choices that you outlined appear to be different in terms > > whether > > we solve the general problem and probably have some minor > > performance > > impact or we solve the ad-hoc problem but make the system more > > entangled. Here I'm more inclined to the first choice because this > > particular scenario the performance impact should be negligible. >=20 > For the problem at hand there's no question about a > performance effect. The question is whether doing this for _other_ > RCU callbacks would introduce a performance drop in certain cases. >=20 Well, I personally favour the approach of making the piece of code that plays with the context responsible of not messing up when doing so. And (replying to Igor comment above), I don't think that syncing context before RCU handlers solves the general problem --as you're calling it-- of "VMX code asynchronously messing up with the context".=20 In fzct, it solves the specific problem of "VMX code called via RCU, asynchronously messing up with the context". There may be other places where (VMX?) code messes with context, *not* from within an RCU handler, and that would still be an issue. All that being said, given the nature of RCUs themselves, and given the "precedent" we have for tasklets, I don't think it's a problem to sync the state in rcu_do_batch(). Looking at users of call_rcu() (and trying to follow the call chains), I think the only occasion where there may be an impact on perf, would be when it's used in del_msixtbl_entry() (e.g., when that is called by msixtbl_pt_unregister())... but I'm not familiar with that area of code, so I may very well be wrong. So, to summarize, if it were me doing this, I'd sync either in vmx_vcpu_destroy() or in complete_domain_destroy(). But (for what it's worth) I'm fine with it happening in rcu_do_batch(). Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli --=-Kqf/UjBXIhwAWggeJXNF 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+4FAloUV4sACgkQFkJ4iaW4 c+5XLg/8CeK70TTScI73muZwAIxLdtVuK8+MAqFh+TOeUo2YPI3k3a//5yNSBCRe 2RpyolZqu0P8nZmJl38KqHx6ckLzrkesXXz5cxCepmSuBEy5JJBAVlB4vo869sAx FIalER9NjIU3+grUpCHIw+T1Qo6xO19geByTfQvMjFZ5ZgTdiJNhq1WxNSr6EI7w LtxTYT53nLfA1Q4wgeeba4l2rzr1YZZ5I4LGJoHj/66pxC+hZOjtauT7Qn7T1l86 ID6IRQoMWTYYjraYrU3Pyj7HSIpYcmZycqaH9qPV1zZdpAXQynO5LDAk6EE235hq LDbswghkGueT8zpb7wey6FGACpcD82SEzqO4TAdegWTitSEXxKmkF6hfb5fxnKE3 KppeXxUNPciKXp0gcFTAE5WrET10wvm+e1F7snsQWE1Ttp5tfyiB81Hs2HYIJm4Q QhboW8P3Jg7b1VFWSYHmPHr23g0QLhzbYW7HdojOsFMu/wvvVwmIXZGy24YL6/74 lEiNykKOayxXUIzk+y/R9vKXiC3W7BpxHr/5DnU+B5eYuqyeIeTI5Fl/kpz1pRdh jyi8Zb4276FjxWoldokT2+8auHu6spiU+e66z5RTAUQLuCIf+GcHhX4omf5qg374 5UjgWk9D9y8bTPkn9aa3+LD83xYkybiTcQx4j+GPddUyGTcb+Wg= =kTly -----END PGP SIGNATURE----- --=-Kqf/UjBXIhwAWggeJXNF-- --===============0938207360114377291== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0938207360114377291==--