From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks Date: Tue, 20 Sep 2016 01:12:08 +0200 Message-ID: <1474326728.4393.90.camel@citrix.com> References: <1472615791-8664-1-git-send-email-feng.wu@intel.com> <1472615791-8664-5-git-send-email-feng.wu@intel.com> <57C8030F020000780010ABEF@prv-mh.provo.novell.com> <57C94099020000780010B115@prv-mh.provo.novell.com> <57C95162020000780010B1B3@prv-mh.provo.novell.com> <57C961B3020000780010B27E@prv-mh.provo.novell.com> <57C97470020000780010B354@prv-mh.provo.novell.com> <57C9A0C1020000780010B642@prv-mh.provo.novell.com> <1473864713.6339.142.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5308661713691583397==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: "Wu, Feng" , Jan Beulich Cc: "george.dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "Tian, Kevin" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============5308661713691583397== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-PGwgjbvZI/5pSW7Ei1Ny" --=-PGwgjbvZI/5pSW7Ei1Ny Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2016-09-18 at 08:37 +0000, Wu, Feng wrote: > > From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > > So why this is all of the sudden becoming one? Am I completely off > > with > > my recollection (or in general :-P)? Or what am I missing about the > > issue we are trying to address with this new bits of the work? >=20 > The issue discussed between Jan and me is that now we have four > PI hooks: vmx_pi_switch_from, vmx_pi_switch_to, vmx_vcpu_block, > and vmx_pi_do_resume. The previous assumption in vmx_vcpu_block() > is that when we are running this function, the NDST field should have > the same meaning with the current pCPU the vCPU is running on. > I'm sorry, but I'm still not getting it. Feel free to drop me, if I'm doing more harm than good, but really, I can't parse this sentence into something that makes me better understand the problem at hand. "The previous assumption": "previous" with respect to what? "the field should have the same meaning with the current pCPU the vCPU is running on", what's this meaning you're mentioning, and how would it be the same? > However, I found this is not true in some scenarios, such as, > vmx_pi_switch_to() hasn't been installed or executed before > vmx_vcpu_block() gets called, in which case, we may hit the ASSERT > in it. In previous version, I suggested we remove the ASSERT in > vmx_vcpu_block() and set NDST explicitly in it. But seems maintainer > doesn't like this idea.=20 > And this is not helping either. An ASSERT() being hit means something wrong happened. Whether or not to remove (or change) an ASSERT() is not a matter of "like". If we hit the ASSERT() but nothing is wrong with the code, then it is the ASSERT() itself that is wrong (buggy), and we must remove it, like it or not. OTOH, if we hit a non buggy ASSERT(), then it means that the ASSERT() has done its job in finding something wrong in the code, and we should leave it alone and fix the problem. How's possible for the solution here to be "either remove the ASSERT() _OR_ change the code"? That really makes few sense to me... :-O Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-PGwgjbvZI/5pSW7Ei1Ny 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 iQIcBAABCAAGBQJX4HDIAAoJEBZCeImluHPuzlMP/A8VkZJom/TmsH1RrxCXWWkD uw2LpsebBH3Drzh5svqQW8E2owzcr8NIXZXPABOKDzUC3QoVmqGHafVfLUSstVoR G6iwGwc9/jufSlpHOucmWJ6OyWboh4f8sE4sGaAi+Kvy5zYxgJ4i43Zifz5OZInB 1LfVIxJMZUtOjkmC5kqkno23sYaC62H2p0yI16L83znOsICh3yHqfLY7VzblSmmJ YkSGdD+0b/OexFA2NHeaTeyOHdm8nK10BAZg4Bap53NI/7jaH+pzw4P2sQMhs9Zz OsLLkceeiNt78ZiQgeljaozg17I3esDqhLuEQ0PWJZufVQuX1Hq0HFmipfM53EUQ RfaDGgvoNl3WY69nmieCM8P47nEeibowNNWB5qT+ir/SdnnAucJ2iGp7v47ozayw g5ffSzEMm/egpH6/2PmN4pS4wSh9jZLZy6/pYvjh+Ccgu6hodrTm+p+4zz8b+kGL N8UV5PZOTCp+gvpeYQfvQndnKZU7Q/4p3n+uI43tDeFnlWOc+iEjSmd/IS1tubto Yqa7qxrxV7RRY2iNmPUmVO5udzXD3d+BCXUdBZ6IOGOnSrdWqH/xXQvr+4rTbLLX Q4TLweE08GdXTREL2XnjnXfipr2bKMdstnDp0Dcr+0w+DuQbZKlZBZMbgmyOXu9Y i867tNUhMIUClrl1ZI4/ =fG1M -----END PGP SIGNATURE----- --=-PGwgjbvZI/5pSW7Ei1Ny-- --===============5308661713691583397== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5308661713691583397==--