From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT0V8-0001ZI-F5 for qemu-devel@nongnu.org; Fri, 29 Jul 2016 01:38:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bT0V6-0001Km-3J for qemu-devel@nongnu.org; Fri, 29 Jul 2016 01:38:25 -0400 Date: Fri, 29 Jul 2016 15:40:15 +1000 From: David Gibson Message-ID: <20160729054015.GR2588@voom.fritz.box> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o0y1lerN6xYE2ROn" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] target-ppc: SPR_BOOKE_ESR not set on FP exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alarson@ddci.com Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, agraf@suse.de --o0y1lerN6xYE2ROn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2016 at 06:32:27PM -0500, alarson@ddci.com wrote: > The target-ppc/excp_helper.c:powerpc_excp() case POWERPC_EXCP_FP fails > to set "env->spr[SPR_BOOKE_ESR] =3D ESR_FP;". I can submit a patch for > that, Ok, please do. > or anyone can add it, but I notice that in the other cases where > SPR_BOOKE_ESR is set, the "msr" is ALSO set. Since the "msr" is used > to initialize SRR1, there is a possibility of inadvertently enabling > BookE MSR bits indirectly. > Given that this code is not performance > sensitive, I think it would be safer to set EITHER msr or the ESR, but > not BOTH. For example: >=20 > if (excp_model =3D=3D POWERPC_EXCP_BOOKE) > env->spr[SPR_BOOKE_ESR] =3D ESR_FP; > else > msr |=3D 0x00100000; That does seem sensible, assuming those srr1 bits are no correct for BookE, which they're not IIRC (ESR takes their place). > I did a quick check of the bits set in the POWERPC_EXCP_PROGRAM case. > The classic PPC sets SRR1 bits 11--15 depending on the exception. In > Book E these correspond to bits 43--47, Um.. what? I'm not understanding where this bit shift is coming =66rom. The exception code is setting MSR directly, so it should be the same bit numbers, although they might have a different meaning on BookE to BookS. > of which (according to my > EREF) only 45 and 46 are currently defined. BookE MSR bits 45 (Wait > state enable) and 46 (Critical Enable) correspond to classic SRR1 bits > 13 (exception is TRAP) and 14 ("SRR0 is not faulting instruction"). > If I understand the current code, given this aliasing then when a TRAP > exception occurs on a book E processor it will effectively enable wait > state, and an FP exception (which sets bit 14/46) will set "Critical > Enable". I'm not sure that either of these features is currently > implemented so this may not have a downstream effect, but never the > less it seems incorrect. I'm not sure about your analysis of which bits are affect, but yes this definitely does seem wrong. > I can submit a patch for the ESR_FP, and/or a change to have the > "either or but not both" settings of MSR and ESR. Please let me know > which you'd prefer. Both fixes please, as separate patches. --=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 --o0y1lerN6xYE2ROn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXmuw/AAoJEGw4ysog2bOSl5MQAOArTSjMRrA/ZlNvyNy2P1CF g9JRbUKH1WjbKoL/44S5Eq9orMUX9m2LA4nhCnTk7j2Ly8MTqpvFlv0vPmVY35Sn xhagTztUdJkX9aYK6PrOa6AdcVU6Nq0G+CQ3m2gQPPzyDXYwlh09qr3gHBalrnr0 yNFh8aQr2cgq1AffniOqqozrRz/UGcZUkiUs0aSB8asOeWiEAkmgtgCfl2suPN1u hP66kSRAd7GxKO5VlTuabmELBZmOsEC8xd2QKlAsy3LCgK/Tq91WMLSlZOG/E7gS f1VQr36DjHn724j01ZhHqdaWYHMh12t/J9u/R9UNfPrJFyjHOGXK+zAs+B+G+8aL +Az0kqgSEm61UY1U79ti0tCjjikCaDHuAXMTSDuvNvnzpswl6U3/m2WQ3+521ptM 9FRpbnODqehd4ixKxtqI3cbX4qYqm25HJ1ddLFgBqGqBzcrA3ndaspI3snzMGas/ 7GHIJMUUNsfr6o172oLWdLP7kM1zUCiGB6Hxtk9ZWDb64ypuZ1TIiEfWRdg/aFyX eIz2jHyOUEZRfvTqQJCRTrh6kfsHx3HNTXXqOEeBVqdiQC2yQL/IUcR97xKKTw6O lU/kCz/cfLKTyLzsJIiUuXFNiEVh4t8nPra5pEVuHUO+UcuKQhDgYDTAHSi2TUZ6 iX9z+zEst6JHAoq6yIY7 =C4ky -----END PGP SIGNATURE----- --o0y1lerN6xYE2ROn--