From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btbF4-0007RZ-Ow for qemu-devel@nongnu.org; Mon, 10 Oct 2016 10:07:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btbEz-0003Z1-Oe for qemu-devel@nongnu.org; Mon, 10 Oct 2016 10:07:45 -0400 Received: from ozlabs.org ([103.22.144.67]:49045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btbEz-0003YQ-Cz for qemu-devel@nongnu.org; Mon, 10 Oct 2016 10:07:41 -0400 Date: Tue, 11 Oct 2016 00:39:54 +1100 From: David Gibson Message-ID: <20161010133954.GJ22498@umbus.fritz.box> References: <1475835267-7300-1-git-send-email-lvivier@redhat.com> <20161007124849.7c867d79@bahia> <20161010045552.GC22498@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="enLffk0M6cffIOOh" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2] qtest: ask endianness of the target in qtest_init() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Greg Kurz , Laurent Vivier , QEMU Developers --enLffk0M6cffIOOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2016 at 10:18:40AM +0100, Peter Maydell wrote: > On 10 October 2016 at 05:55, David Gibson w= rote: > > However right now - until we get fixed-endianness qtest accessors of > > some sort - this test is more or less necessary to make most tests > > cross platform correct (except PCI, see below). That's because the > > testcase will generally know the endianness of the hardware it's > > testing, but has to compensate for the endianness that the > > readw/writew primitives will use along the way. >=20 > The test case isn't testing the hardware (device), though, it's > testing the hardware in a system. The same device in QEMU board A > could be behind a bridge or otherwise differently wired by > the SoC from the device in QEMU board B. The qtest setup > doesn't instantiate a device and talk directly to it, it > instantiates a board and talks over the same interface the > emulated CPU would. If your bridges change the effective endianness of your device, then your bridge hardware design is broken. Such boards exist but they are, thankfully, rare. In the overwhelming majority of cases the endianness of the device is known independent of the guest CPU and board. --=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 --enLffk0M6cffIOOh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX+5opAAoJEGw4ysog2bOSxZsP/iSoYz9XWw0J/RiDvETrut4d 3ODRHHjcwXedAggrHSdyvZgsGBD1AwmuDpYgHZYctguIeQyH4grtOlS0ZY4P/L7t pID+X9mkvsImw0rQV6a11dc4OMyiuy5vTilPjKWq3ckudDCrmS2VW/51Wipw1NjI Ve4+kd+0Y/CjNL1ZbhpQHQf+ODgcpgdOq7oFpP5WHjkXs/tcYsVdNW2sOpmDQgJI b3+Ul31g2EfKb3pIqHIec1vTpWrvFooaaY44HJHP+SXfQn60S58YInmrMvp4BebP SWmDHk0RkJsSBAlVbLIt1L5GvwpFZBqUNhV8gOJqMFyUQypuK/9LI7u11geynh62 upuzK49jsHw20koIIORkPkFCeXf9cMXiZEA9VBuGINuFbAiPFyXE6NJLl6RQpx2F 1Hr1F9H5ookwDWWF1BJmuE5AmhSDmefeAPWcL1+YYrs8KmqXbvYa1bzVWvTwyxs2 89WX9qEkWbeKHKzH78Z+GxkXeI39we6vI6JQQHEM3wPPCTcjffHElmXlUHrD2JqS zyda/fQbjKElvwp+SiE8pWz0y84+oNSCHYLDUDHYYrsC0NL3dUOplgSWnIv/r4Kj 8/e/IxFQ3F69djFy2HDUTzUcqn/1vMfsb923wGCrk7/mGVVJz9Kl6BZQxxYqU15g HSPC5Q2zyerzKeus+Efe =OMV/ -----END PGP SIGNATURE----- --enLffk0M6cffIOOh--