From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XotkW-0000kQ-TU for qemu-devel@nongnu.org; Thu, 13 Nov 2014 07:43:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XotkV-0002uE-5D for qemu-devel@nongnu.org; Thu, 13 Nov 2014 07:43:44 -0500 Date: Thu, 13 Nov 2014 23:44:54 +1100 From: David Gibson Message-ID: <20141113124454.GB18600@voom.fritz.box> References: <20141105071019.26196.93729.stgit@aravindap> <20141105071315.26196.68104.stgit@aravindap> <20141111031635.GF15270@voom.redhat.com> <5461B04F.5080204@linux.vnet.ibm.com> <20141113035206.GH7291@voom.fritz.box> <54644886.9050803@linux.vnet.ibm.com> <20141113103235.GK7291@voom.fritz.box> <54649A80.5000204@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <54649A80.5000204@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v3 4/4] target-ppc: Handle ibm, nmi-register RTAS call List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aravinda Prasad Cc: qemu-ppc@nongnu.org, benh@au1.ibm.com, aik@au1.ibm.com, qemu-devel@nongnu.org, paulus@samba.org --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2014 at 05:18:16PM +0530, Aravinda Prasad wrote: > On Thursday 13 November 2014 04:02 PM, David Gibson wrote: > > On Thu, Nov 13, 2014 at 11:28:30AM +0530, Aravinda Prasad wrote: [snip] > >>>>> Having to retry the hcall from here seems very awkward. This is a > >>>>> private hcall, so you can define it to do whatever retries are > >>>>> necessary internally (and I don't think your current implementation > >>>>> can fail anyway). > >>>> > >>>> Retrying is required in the cases when multi-processors experience > >>>> machine check at or about the same time. As per PAPR, subsequent > >>>> processors should serialize and wait for the first processor to issue > >>>> the ibm,nmi-interlock call. The second processor retries if the first > >>>> processor which received a machine check is still reading the error = log > >>>> and is yet to issue ibm,nmi-interlock call. > >>> > >>> Hmm.. ok. But I don't see any mechanism in the patches by which > >>> H_REPORT_MC_ERR will report failure if another CPU has an MC in > >>> progress. > >> > >> h_report_mc_err returns 0 if another VCPU is processing machine check > >> and in that case we retry. h_report_mc_err returns error log address if > >> no other VCPU is processing machine check. > >=20 > > Uh.. how? I'm only seeing one return statement in the implementation > > in 3/4. >=20 > This part is in 4/4 which handles ibm,nmi-interlock call in > h_report_mc_err() >=20 > + if (mc_in_progress =3D=3D 1) { > + return 0; > + } Ah, right, missed the change to h_report_mc_err() in the later patch. > >>>> Retrying cannot be done internally in h_report_mc_err hcall: only one > >>>> thread can succeed entering qemu upon parallel hcall and hence retry= ing > >>>> inside the hcall will not allow the ibm,nmi-interlock from first CPU= to > >>>> succeed. > >>> > >>> It's possible, but would require some fiddling inside the h_call to > >>> unlock and wait for the other CPUs to finish, so yes, it might be more > >>> trouble than it's worth. > >>> > >>>> > >>>>> > >>>>>> + mtsprg 2,4 > >>>>> > >>>>> Um.. doesn't this clobber the value of r3 you saved in SPRG2 just a= bove. > >>>> > >>>> The r3 saved in SPRG2 is moved to rtas area in the private hcall and > >>>> hence it is fine to clobber r3 here > >>> > >>> Ok, if you're going to do some magic register saving inside the HCALL, > >>> why not do the SRR[01] and CR restoration inside there as well. > >> > >> SRR0/1 is clobbered while returning from HCALL and hence cannot be > >> restored in HCALL. For CR, we need to do the restoration here as we > >> clobber CR after returning from HCALL (the instruction checking the > >> return value of hcall clobbers CR). > >=20 > > Hrm. AFAICT SRR0/1 shouldn't be clobbered when returning from an >=20 > As hcall is an interrupt, SRR0 is set to nip and SRR1 to msr just before > executing rfid. AFAICT the return path from the hypervisor - including for hcalls - uses HSSR0/1 and hrfid, so ordinary SRR0/SRR1 should be ok. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUZKfGAAoJEGw4ysog2bOSPcIP/0KTL1BsCWPOnFN0qwfM4B5z gAOcxjcmxRAYiEOz/37nzK90d5opqta1QS0KG9qxb7Cqw7vPiYG/mxv6MJ76DyEH 1Con69GQTchacIc6KLwEKfEsHW6Wv7cjSRvILFeZhCy71Fn96962sC2iajaduDU8 bYcnkU4Xbm5vhwb66XXe8TmJubbjA6ML8Gv2T32N1+CWdOJ9aHFJfW6F46ca0xp7 KyduojM9EZ1aMSQoUPelElNEvO/b2u/Mwvr/FuYMEa7HI7G8HoWtetsv1/wMP4AY CQSevvKz7wXzD5AMhvQKlmWptfF+XQesjxw0+iapIXKfH0O66oyYt3zCC1B6Q4t6 a6vb5okWH+OKwzIUcJLj9ClAkBTfquW5m+A03ALI/dAAbBNc1syTCW66Ss1atRSA ZX9bURyG9XM+J9mnKfE8z2rnNZSwjyufA/7BaSjZKqpksPDwUHfANur303/OConp hEbMfKv/pkn/qIC02z4gXLe+O8Pjxtgg8eMPArMi8fbr2V0uFGy1r7Pdz3zrPzT1 rfR7ahEVzHdoB248UwK0aTuxNU2Vn6Dy2M6QSVW39CGVqefdOePEDlkPSZ0HiCrI /gjvOoECHZQLkfWNUmojDmLOHdWKN8Wt4BVsQr8RwSygQ6FPPEzaAs2oUhTsNbup 84vuqgfNWge/xXpnU4QY =e6at -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz--