From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brzkp-0005A5-3c for qemu-devel@nongnu.org; Wed, 05 Oct 2016 23:53:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brzko-0007CL-0y for qemu-devel@nongnu.org; Wed, 05 Oct 2016 23:53:55 -0400 Date: Thu, 6 Oct 2016 14:53:44 +1100 From: David Gibson Message-ID: <20161006035344.GF18733@umbus.fritz.box> References: <1475088693-29091-1-git-send-email-lvivier@redhat.com> <1475088693-29091-2-git-send-email-lvivier@redhat.com> <20160929052745.GQ8390@umbus.fritz.box> <08ecf131-8749-c468-58ea-3f9369fece07@kaod.org> <20161003160314.54771281@bahia> <20161004002454.GC18648@umbus.fritz.box> <20161004085835.29402918@bahia> <20161005011405.GG18648@umbus.fritz.box> <20161005093405.3c0f769f@bahia> <20161005213306.2cfd30d5@bahia> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fwqqG+mf3f7vyBCB" Content-Disposition: inline In-Reply-To: <20161005213306.2cfd30d5@bahia> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/6] libqos: add PPC64 PCI support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: =?iso-8859-1?Q?C=E9dric?= Le Goater , Laurent Vivier , thuth@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Gerd Hoffmann , dgibson@redhat.com --fwqqG+mf3f7vyBCB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 05, 2016 at 09:33:06PM +0200, Greg Kurz wrote: > On Wed, 5 Oct 2016 09:34:05 +0200 > Greg Kurz wrote: > > On Wed, 5 Oct 2016 12:14:05 +1100 > > David Gibson wrote: > > [...] > > You convinced me. The tswaps in qtest.c are toxic and should be removed. > >=20 > > Thanks for the clarification. > >=20 >=20 > Rewind. Cedric and I spent the whole day thinking about that, based on > Peter's inputs. The conclusion is: the qtest accelerator replaces the > real world CPU and and the test program simulates what the CPU actually > does when running the guest driver code in a specific situation. No, I still think Peter is dead wrong, as you can see in my various replies "What the CPU actually does" depends on a number of factors which simply aren't modelled when qtest replaces the cpu, so it's not a meaningful concept. > If the guest driver performs a store to the device, and the CPU and > device have different endianness, cpu_to_xxYY() in the driver code > boils down to bswapYY(). Doing things like writel(cpu_to_beYY()) in > the test program is thus wrong since it involves the host endianness, > and the test program no longer simulates what the real CPU would do. > The test program must hence do writel(bswapYY()) and send that to > qtest. Except that the bswap has to be conditional on whether the guest CPU's notional endianness is the same as the device or not. So, for say an LE device that can appear on several platforms what we actually need writel(guestcpu_to_le32(val)). Except that if host and guest (notional) endianness are different the result of that conversion won't *actually* be LE32, it will be a swapped value in anticipation of the swap back to guest endianness within the writel(). Why not just say what you actually want. We want to write to an LE device, so writel_le(val); > If the host endianness differs from the simulated CPU, the value is in > wrong order and must be byteswapped before being handed over to the memory > layer. >=20 > This explains why qtest calls tswapYY() before cpu_physical_memory_write(= ). Yes, the tswap() correctly implements an operation with semantics that are approximately never what you want. --=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 --fwqqG+mf3f7vyBCB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9crHAAoJEGw4ysog2bOSgFwQAKbvW4F3eBDTnMS8PHDvG215 yvDSU/4z1UR9VZhLBpmCKzomwgWbz28JAtPM+5C9T/0+d1p9gcNWy2XQpQ+rKlxD xrOXMmGi9glMv+BPmpvwpjgHAp0O3xFa9Gw4WV/3uWvN3nJldtu9Ggb5Vy7XwTeA 0tUidQLJ3ijMhkJ8DW/x/eOYDvou3YnG1bR8G3UCULoqZqi3rK57gLmRDrJsc0Y9 rds36vSDy9KU+3s+rOJ1cMzmQHXvygDLGi6N6sfIsmw5RzGgdJXArCsWvvFwOOn+ l18oKK1ilpiHVaHg2B0E+oAuz0MoZN6Sn7/3rrDjTwJcGBZQHris55e8SSLrRbHa 7SX0vM1cusnGGkgUlGrOd9zmXtBR1ylnJZtvpEVkOVzKvfQExkTIS2t1GLTS6Xvn rOu5De8V7OxN4dMUKSfRXbI+9TwsS5Eotl3r7GsAcQ7nkzCP96Pm28fJv4ybIdkI 93UXh05FBDSn+HMOavaNSHC9OyguYFX5G+pnclP3jSyc6NU65m6xz8tya/2AeA/F vTc9zKZT0nzbBtTxhAxPXlDUHzlVCKFDCLRGrcWq2gZr1HWzjWYIblUV9nbEupVM 1tyJEVEhYvExAipXqBk4z8MAVuB0gIrMrrb9LrF1cDv00CYOhltedv8eyldvOI2R 4aWYpLrqwdHN4E3rvQ/H =0Yp8 -----END PGP SIGNATURE----- --fwqqG+mf3f7vyBCB--