From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aKzXN-00061D-1F for qemu-devel@nongnu.org; Sun, 17 Jan 2016 21:27:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aKzXK-0006eW-5p for qemu-devel@nongnu.org; Sun, 17 Jan 2016 21:27:20 -0500 Date: Mon, 18 Jan 2016 13:16:44 +1100 From: David Gibson Message-ID: <20160118021644.GG9301@voom.fritz.box> References: <20160115150005.17358.43294.stgit@bahia.huguette.org> <20160115150012.17358.95155.stgit@bahia.huguette.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDnEQgWzhgf+8aPe" Content-Disposition: inline In-Reply-To: <20160115150012.17358.95155.stgit@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 --dDnEQgWzhgf+8aPe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 with > 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 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 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. Is that correct? > --- > target-ppc/kvm.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) >=20 > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 9940a9046220..45249990bda1 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -650,8 +650,13 @@ static int kvm_put_fp(CPUState *cs) > for (i =3D 0; i < 32; i++) { > uint64_t vsr[2]; > =20 > +#ifdef HOST_WORDS_BIGENDIAN > vsr[0] =3D float64_val(env->fpr[i]); > vsr[1] =3D env->vsr[i]; > +#else > + vsr[0] =3D env->vsr[i]; > + vsr[1] =3D float64_val(env->fpr[i]); > +#endif > reg.addr =3D (uintptr_t) &vsr; > reg.id =3D vsx ? KVM_REG_PPC_VSR(i) : KVM_REG_PPC_FPR(i); > =20 > @@ -721,10 +726,17 @@ static int kvm_get_fp(CPUState *cs) > vsx ? "VSR" : "FPR", i, strerror(errno)); > return ret; > } else { > +#ifdef HOST_WORDS_BIGENDIAN > env->fpr[i] =3D vsr[0]; > if (vsx) { > env->vsr[i] =3D vsr[1]; > } > +#else > + env->fpr[i] =3D vsr[1]; > + if (vsx) { > + env->vsr[i] =3D vsr[0]; > + } > +#endif > } > } > } >=20 --=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 --dDnEQgWzhgf+8aPe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnEsMAAoJEGw4ysog2bOSwpwQAKMvCerT3QewezRvTijROdcW ptYt1oGU7Nr2YcCQCzPqyKGGcde1PkQkTE6zHzEbiIiTGkXvGn8nASMvTqecy41c zaFtLis67aLCP4peFOFpztuexydCGEx1Dkq7kAMQ9JAPFcGCH3a1ZMHRN3WL+2GE uFsv9C4OI4AhriG8J5IzwZ6cN9uPDNCsqa3lzD3jDLSYmyZy154aQIw2zFAxcbvT oVGcYWiQ/d/Kh22tcg4hjAO2WCR7/u5kmlTAQZ0Y6ebmiEx7QtrXM4voYENNCwM3 zCICqpuntKQrn7cOKiN0wtmBQmRRDc6xZW9+OSQWWtKq7ZR5d2o99UM91GN6kREX uKgH/jKW99l59xyX8qJQAB13/SL5txT8PtuyRwM4DMSWc0zG0ZK2aQ5xAxOshzMF RsJxsKF09C9dvtsiroeNe76U0o0OIUBQVsrkQkVCNwPdd+wBDXB5loGSfGIKbMbg P7kR10xBTlrns8ydct2EgrLAe9OKjzcULCG083Hl99mybUXYg9RiHkCineklZI5u S16/XHohz3GVbK52DM/LuALIrkZofd/SgEmg0rA4L6+wRB3sGpXJO/imrLrgNP3z 5dhi66pqiRftsNf7vm5qnjZsWGEqjkRoQjpaCWZMHgni7ZuWA0D/laI6XKo1HRt/ atFI3YO2YwXO2ktSlix6 =78L9 -----END PGP SIGNATURE----- --dDnEQgWzhgf+8aPe--