From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsIn9-0000GC-JC for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsIn4-0003Gv-UX for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:34 -0400 Received: from ozlabs.org ([103.22.144.67]:51097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsIn4-0003Gd-J0 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:30 -0400 Date: Fri, 7 Oct 2016 10:43:02 +1100 From: David Gibson Message-ID: <20161006234302.GE18490@umbus.fritz.box> References: <1475583448-21013-1-git-send-email-clg@kaod.org> <20161004234352.GE18648@umbus.fritz.box> <20161006033836.GC18733@umbus.fritz.box> <20161006161142.1d56f98c@bahia> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FEz7ebHBGB6b2e8X" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] qtest: add read/write accessors with a specific endianness List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Greg Kurz , Peter Maydell , QEMU Developers , Laurent Vivier , =?iso-8859-1?Q?C=E9dric?= Le Goater --FEz7ebHBGB6b2e8X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2016 at 05:36:32PM +0200, Paolo Bonzini wrote: >=20 >=20 > On 06/10/2016 16:11, Greg Kurz wrote: > > FWIW, Cedric had another proposal which apparently went unnoticed: > >=20 > > > >=20 > > The idea is to add an optional endianness argument to the read*/write* > > commands in the qtest protocol: > > - libqtest then provides explicit _le and _be APIs > > - no extra byteswap is performed on the test program side: qtest > > actually handles that and does exactly 1 or 0 byteswap. > > - it does not use memread/memwrite > > - the current 'guest native' API where qtest tswaps is preserved > >=20 >=20 > No, this is a worse idea, because the right place to do the swap is in > the "program" (libqtest) not in the "CPU" (QEMU). Hrm.. I guess that makes sense from an x86 perspective when load/stores always operate in LE. Not so much for something like Power where the CPU can perform both LE and BE load/stores trivially. You can select with CPU mode combined with which instruction form you use. e.g. the always-LE writel() on a BE Power kernel is a single byte-reversed store instruction[0]. there's no "swap" as such, and the swapped value never appears in a register. I'm not certain if gcc is smart enough to translate foo->bar =3D cpu_to_le32(val) into a byte-reversed store, but it might be. The value passed across the pipe to readw etc. is text, so it has no endianness, just as a value in a cpu register has no endianness. To me it makes perfect sense to tell the qtest "cpu" which endianness of load/store you want it to do with that. [0] Well, ok, there's a memory barrier too, so it's not quite 1 instruction. --=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 --FEz7ebHBGB6b2e8X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9uGFAAoJEGw4ysog2bOS0nEP/2PhHvLJUpeDuDibeDUhAWWs tKhqFRX9JgdfPGMUviMvj26FsDb+1Pe+T181Z8jeRYT16gA9W24wmJPysfhmWEcK G/52uyeIZcIM0YVkIa4wPg0XffE/oJEHQPo+cK8aConoGdZhChb3pKQbRkO0mUSI gHhSlALbqJsubVI0aHQ/tYAAvcEechT2HCsMpHuHJe57LtVbBcNFA4CFfEsFyJEW 4ZuSfQY/mnOaNC7Oij+krvMFbJ4MuWXlFS7hydUMULRFOm3pKLM3eJvsq7bg8ZIR O9I81UPVdv4F7XqR+59DpPxjXCy32wwMHgvRWY20cXlSf4NibJ4Egij1idaUYphy LiyFGTyQhCzEBHVCdU8AdLtzqdVbMshdWAXgWWa+Xsk3cNOyN5jmW0YZdT3f9eka N4U8UBP8AsYAfE5Ni7U+mUWmQHdWts+GAeLbVNxVJTj310dXLG2FicpPTt7IXLAD IPREihM/MdHuY9fGgBAcKro+fHGWZx9y1HSaCcL088574hOVS8RJI3qU1+ZPxGCy mhImSQgiHHLmZbX3cu2qQKLFhp7lxrZt7/tbOuf5yB2sFAr6P6UgKr9Z5bwsOvv3 JCHADhIeEdF7M1X+eQoekk+IkErPCGoXqQARzMrrLe1wkA/n5opFsdptdG2+Bx5x zm1BgDJdGNojFv8W53ZK =mA3A -----END PGP SIGNATURE----- --FEz7ebHBGB6b2e8X--