From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx8Ox-0006DO-0B for qemu-devel@nongnu.org; Fri, 13 Nov 2015 02:04:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zx8Or-0001yL-FA for qemu-devel@nongnu.org; Fri, 13 Nov 2015 02:04:02 -0500 References: <20151111171135.4328.41819.stgit@aravindap> <20151111171602.4328.34006.stgit@aravindap> <56444957.9080003@redhat.com> <56445E7B.5010904@redhat.com> <20151113015715.GJ4886@voom.redhat.com> From: Thomas Huth Message-ID: <56458B57.3010407@redhat.com> Date: Fri, 13 Nov 2015 08:03:51 +0100 MIME-Version: 1.0 In-Reply-To: <20151113015715.GJ4886@voom.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tpfkpfbDG6gUdGHl3eNtXpoRI83XCB2JU" Subject: Re: [Qemu-devel] [PATCH 4/4] target-ppc: Handle NMI guest exit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: benh@au1.ibm.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, sam.bobroff@au1.ibm.com, Aravinda Prasad , paulus@samba.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tpfkpfbDG6gUdGHl3eNtXpoRI83XCB2JU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/11/15 02:57, David Gibson wrote: > On Thu, Nov 12, 2015 at 10:40:11AM +0100, Thomas Huth wrote: >> On 12/11/15 09:09, Thomas Huth wrote: >>> On 11/11/15 18:16, Aravinda Prasad wrote: [...] >>>> + qemu_mutex_lock(&spapr->mc_in_progress); >>> >>> Using a mutex here is definitely wrong. The kvm_arch_handle_exit() co= de >>> is run under the Big QEMU Lock=E2=84=A2 (see qemu_mutex_lock_iothread= () in >>> kvm_cpu_exec()), [...] >> Ok, I now had a look into the LoPAPR spec, and if I've got that right,= >> you really have to serialize the NMIs in case they happen at multiple >> CPUs at the same time. So I guess the best thing you can do here is >> something like: >> >> while (spapr->mc_in_progress) { >> /* >> * There is already another NMI in progress, thus we need >> * to yield here to wait until it has been finsihed >> */ >> qemu_mutex_unlock_iothread(); >> usleep(10); >> qemu_mutex_lock_iothread(); >> } >> spapr->mc_in_progress =3D true; [...] > You should be able to avoid the nasty usleep by using a pthread > condition variable. So here you'd have >=20 > while (spapr->mc_in_progress) { > pthread_cond_wait(&mc_delivery_cond, &qemu_iothread_lock); > } > spapr->mc_in_progress =3D true; >=20 > Or.. there may be qemu wrappers around the pthread functions you > should be using. Once delivery of a single MC is complete, you'd use > pthread_cond_signal() to wake up any additional ones. >=20 > pthread_cond_wait automatically drops the specified mutex internally, > so access to mc_in_progress itself is still protected by the iothread > mutex. That's a nice one, didn't know that function yet! And actually, there is already a QEMU wrapper function: qemu_cond_wait() - so this should be used instead since threads on Windows are working differently in QEMU as far as I know. Thomas --tpfkpfbDG6gUdGHl3eNtXpoRI83XCB2JU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWRYtXAAoJEC7Z13T+cC21ffkP/2Wlji9Bmo/6py2dOHRZqiOJ hlvxcuV4fiUCqguZ26MMovDdJSdJYqzgzxNuv37zVTRj6LDfa9v1e6v3oFpvT4lS a2EjPq+k96uBtl7fkFsJyK7/DW1sJ426xWKlT/zVyWgsW8vr6hQHVpdYIvaCVJnX /cx/qYAZ678JdTSaiXq3fDzNtXZBmgsb3ATH3uEm8bBdGuOoeHiZ8Y0sy9MAj/Xc 9EdWE/lmNxnfGHfaFF0xOw/CXHRE0836K/0ULa3uPw2gu6sMyLwKH6GpQlzghpiG +q1LhphcA69KfWmtyv7l3Yt0R1DXh6haGjbIIAUOh8Bj5jHa4R3IKl/fNfNLzq25 jLV8kTBrX1fpGtyKX3Qraz4MzHKGlCzP2dKFf5HrCl438f//LRsaYHvsoYDrukQt pWwdi8WjJcHJDW22SZEMrUCL/inkdoH0rY2a0dFv7O5RZknB0OYz40SZ9KNdZqfc sSVYeywKue0LQJRQ7vl3p+uftCHavahUyS9f5Dkg2d9Z8uB9aK6p6tRBKAxBS70b gDHUjeylMQ+FzGad7LpvZDs5ElBUgDhklemPs/GPcmPb51J5oLUFwkfqdplB1pm8 KFGqWgOiVb9GyWy78lnSi1B7+hxpzWJ/6gv/DlnSWVIwfuY6r2rDzNb3/9sMDRae yHlC3b03ojEYucBxLz6F =75sR -----END PGP SIGNATURE----- --tpfkpfbDG6gUdGHl3eNtXpoRI83XCB2JU--