From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLKhS-0005i8-Ey for qemu-devel@nongnu.org; Mon, 18 Jan 2016 20:03:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLKhO-0007cE-6C for qemu-devel@nongnu.org; Mon, 18 Jan 2016 20:03:10 -0500 Date: Tue, 19 Jan 2016 11:55:10 +1100 From: David Gibson Message-ID: <20160119005510.GU9301@voom.fritz.box> References: <20160115150005.17358.43294.stgit@bahia.huguette.org> <20160115150012.17358.95155.stgit@bahia.huguette.org> <20160118021644.GG9301@voom.fritz.box> <20160118095156.31bcbdc4@bahia.huguette.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iytlPraCFSCqrfnM" Content-Disposition: inline In-Reply-To: <20160118095156.31bcbdc4@bahia.huguette.org> Subject: Re: [Qemu-devel] [PATCH 1/7] target-ppc: kvm: fix floating point registers sync on little-endian hosts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: qemu-devel@nongnu.org, Paolo Bonzini , qemu-ppc@nongnu.org, Alexander Graf , Anton Blanchard --iytlPraCFSCqrfnM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 18, 2016 at 09:51:56AM +0100, Greg Kurz wrote: > On Mon, 18 Jan 2016 13:16:44 +1100 > David Gibson wrote: >=20 > > On Fri, Jan 15, 2016 at 04:00:12PM +0100, Greg Kurz wrote: > > > On VSX capable CPUs, the 32 FP registers are mapped to the high-bits > > > of the 32 first VSX registers. So if you have: > > >=20 > > > VSR31 =3D (uint128) 0x0102030405060708090a0b0c0d0e0f00 > > >=20 > > > then > > >=20 > > > FPR31 =3D (uint64) 0x0102030405060708 > > >=20 > > > The kernel stores the VSX registers in the fp_state struct following = the > > > host endian element ordering. > > >=20 > > > On big-endian: > > >=20 > > > fp_state.fpr[31][0] =3D 0x0102030405060708 > > > fp_state.fpr[31][1] =3D 0x090a0b0c0d0e0f00 > > >=20 > > > On little-endian: > > >=20 > > > fp_state.fpr[31][0] =3D 0x090a0b0c0d0e0f00 > > > fp_state.fpr[31][1] =3D 0x0102030405060708 > > >=20 > > > The KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls preserve this ordering= , but > > > QEMU considers it as big-endian and always copies element [0] to the > > > fpr[] array and element [1] to the vsr[] array. This does not work wi= th > > > little-endian hosts, and you will get: > > >=20 > > > (qemu) p $f31 > > > 0x90a0b0c0d0e0f00 > > >=20 > > > instead of: > > >=20 > > > (qemu) p $f31 > > > 0x102030405060708 > > >=20 > > > This patch fixes the element ordering for little-endian hosts. > > >=20 > > > Signed-off-by: Greg Kurz =20 > >=20 > > If I'm understanding correctly, the only reason this bug didn't affect > > things other than the gdbstub is because the get and put routines had >=20 > Well it is not only gdbstub actually... as showed in the changelog, it al= so > affects the QEMU monitor which outputs wrong values since it calls kvm_ge= t_fpu() > as well. Yes, sorry, I didn't express that well. My point is that the only reason things aren't going horribly wrong is that qemu is only ever touching the FP/VSX values for debug, and the get/put into KVM is wrong in such a way that the right values go back again as long as qemu doesn't try to change them. > > mirrored bugs. So although qemu ended up with definitely wrong > > information in its internal state, it reshuffled it to be right on > > setting it back into KVM. > >=20 > > Is that correct? > >=20 >=20 > My guess is that the bug only affects gdbstub and ppc_cpu_dump_state(), b= ecause > these are the only cases where QEMU parses the state of FP registers... t= his > is indeed confirmed by the KVM bug you are referring to, that had no visi= ble > effect for more than a year BTW. Ok. Still waiting for a reply for my query on 5/7, then I'm happy to apply these. --=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 --iytlPraCFSCqrfnM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnYluAAoJEGw4ysog2bOSiDAP/1Qh4N4KGl7a0q7zfvJLjorF KJnJjhmB9/WV2zPQ8f9F1LobtpFAiHgaq436CO2eu+n+UrZsGXfUvkvm33XM3eLK FVv4vf7K0tMxmftRbEWc+tu1TWXwkppZtHNpXu6wnJKE41OcK+aMRnrhIktzOyzx KbGFl856mqk3W+UR3KcvwMltFlVwI6M6ZrRC2ydYMehDfyu+xQNEDHXpkLIEc/s3 Q/YHSS23VyEJmducHo+w0ZCO2QaKAHWg1qINSQDJKfIh3+x0jnvVKkfryIv0NEN0 VzOtyDde62Rax78ljUVRcBQOMH6UcO0xp3KyCUlw1upOHOC7G9zRDj52KA+jRpFE W/eHMUSB75v0w/pK3xAb0GqtUj3eF3c5Pgru8F47CJJduoE+LkbT2h0PEq5Gudf7 i6pfxHqY3Y412KXevXBqDb383wWn/uLINyZ6OuM+CZnJ5NPHqEeOqDsKUiVNOUQl y7YDaWPwermIpUzmel/Yt3bNILGGIOxkUd7aucd3XPLpSTI+w8/djNRci9ppgdsp 81ltap0ojbysNliWpBECdGXYGGC6N25TQh0VO8lwMW7MNMHUELOCTmnKv0GYZqDL G6/7wg6icLLF655gf5P78rvsbDYlnPmvZeU5ZRxkZD8Qfqy/VoKoLe7/nw/Xun3e SI5PnIZp6QcEcznFnSzo =sd7x -----END PGP SIGNATURE----- --iytlPraCFSCqrfnM--