From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsIn6-0000Fw-EE for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsIn4-0003GY-1d for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:31 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:44789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsIn3-0003Db-CB for qemu-devel@nongnu.org; Thu, 06 Oct 2016 20:13:29 -0400 Date: Fri, 7 Oct 2016 10:09:05 +1100 From: David Gibson Message-ID: <20161006230905.GA18490@umbus.fritz.box> References: <1475583448-21013-1-git-send-email-clg@kaod.org> <20161004234352.GE18648@umbus.fritz.box> <65e1a873-c9a2-b93e-4680-d1fa5f86316d@kaod.org> <20161006034543.GE18733@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" 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: Peter Maydell Cc: =?iso-8859-1?Q?C=E9dric?= Le Goater , QEMU Developers , Greg Kurz , Laurent Vivier --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2016 at 11:47:36AM +0100, Peter Maydell wrote: > On 6 October 2016 at 04:45, David Gibson wr= ote: > > On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote: > >> On 5 October 2016 at 07:00, C=E9dric Le Goater wrote: > >> > On 10/05/2016 03:53 PM, Peter Maydell wrote: > >> >> Which tswap? Last time I worked through the stack of > >> >> what happens I thought that we had the right set of > >> >> swaps in the right places. > >> > > >> > The one I am talking about are under qtest_process_command(), > >> > see below. > >> > >> Those are correct and required, and they do not change > >> the overall behaviour of the system depending on the host > >> endianness. (They convert 32-bit values to "bag of > >> bytes in guest order" which is what the cpu_physical_memory_* > >> functions want.) > > > > These functions are correct for the defined semantics of the > > readw/readl operations, but those semantics are not useful. >=20 > ?? They're the most obvious and required semantics: "act > like the CPU just did a word/halfword/byte read/write". The CPU with what mode and options? > There's a reason we've got this far without needing anything > else, and it's that this is the most straightforward use case. No, I'm pretty sure we've got this far because most of the tests haven't yet been enabled for a traditionally BE target. > > This proposal is introducing alternate functions with the more useful > > semantics which are "convert a 32-bit value to a bag of bytes in LE > > order" or "convert a 32-bit value to a bag of bytes in BE order" > > depending on which variant you choose. >=20 > It's adding functions whose semantics are "act like the > CPU wrote this value to some RAM and then memcpy()ed it to > the device". I think devices whose usage model is "memcpy bytes > to me" are rare to nonexistent. Uh, that's not the intention. I have some comments on this elsewhere. The intended semantics are that we do a single atomic write to an address, but with a specific endianness. --=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 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9tmOAAoJEGw4ysog2bOSLAYP/0BiloJCWZY544YRmOOy+sHO ekPpLWgnJ2R3o9GY37SEJjzqP9Ml/YpNfsVMgW0UfmYQ7EHmYKLTBSppeZbCgc2r bc3O1pWPhX940f7X9Bp8KJsn1/ZErOyBnzd1qjQq6ruuQ0FDE3z+eQ/1dxTzE7K9 soIXp0gOSfIaEUkX7gB3b9mcnFIyR9pM+SYCl7lPij9ByLujT924l/brr/1UqVU1 uKKI/4jMpioI7H/6kmgzcv/3ZgH5i5zngJHsKL0KbML6i57x6+8+UXN0+pLMyXbX iZPUrJkUEDFUGPVg8xR91oUNhTrTyCQsVxE25rbucvaFSdk+50Z03adff0taU/rR WN1DlnfwbzAICGDekJHOimehFpdikZJ7Cl0VQ3rRv1vVkQTq63ZBtlQ2m9gztUD9 SBaTkaTejsXTXFh9+qque5vmpQtY2bNwIvoiVaw+ZLhgJksfLvAUUlfVW9iyKk4w vU/PIJ9ebzVXHZ0GpNNrXTRrSm7las/LtdIW476HcJ5cfSmMGe5Z+dvwZ8Ls0NCb EfsY7hUIj95zdU0cspS910+sOYVzv0U1Nf+s8rRU0Cavorerd2SHS3l1yzI5c5H/ PVVoMFrhq2xAX7c7yKOWL28F3YqZlhw/wbI8FfWeXiTXUgf+uHGuLXtiQHu4Ccbx Zyjm8CQHK24zokoTOg8r =67+x -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--