From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyzXU-0004pv-JY for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:19:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyzXQ-0004qw-UJ for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:19:12 -0400 Received: from mout.web.de ([212.227.15.14]:49782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyzXQ-0004qp-LL for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:19:08 -0400 Message-ID: <51E4F3C1.5030201@web.de> Date: Tue, 16 Jul 2013 09:18:25 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <51C75FA6.6080903@reactos.org> <51C7E21A.9090005@web.de> <8A36D64D-0625-49E1-9E59-391DAEEBD1FC@suse.de> <51DEA91B.40903@suse.de> <51E16683.1040304@redhat.com> <51E24216.4050406@redhat.com> <874nbxqolf.fsf@codemonkey.ws> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ABHNQETTOURDSLWCGKVD" Subject: Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Liu Ping Fan , Alexander Graf , qemu-devel , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ABHNQETTOURDSLWCGKVD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-14 17:18, Anthony Liguori wrote: > On Sun, Jul 14, 2013 at 9:58 AM, Peter Maydell wrote: >> On 14 July 2013 14:05, Anthony Liguori wrote: >>>> Also, what devices exactly would have a non-native byte order?!? I'= m >>>> confused... >>> >>> MMIO/PIO requests don't have a byte order. It's literally 64 or 32 d= ata >>> pins that are numbered D0..D31 whereas D0 is the LSB. It doesn't mat= ter >>> how the pins are arranged. >> >> Devices themselves do have a byte order, though, right? Specifically, >> if you do a 32 bit read of address 0 on a device and an 8 bit read, >=20 > It depends on the bus and device. Busses don't necessary pass the I/O > size down to the device like that. If it does, the device may do any > number of things (including ignoring the request entirely. >=20 > What's most common AFAIK is that the access is treated as a word > access and then truncated. IOW, the device sees the 32-bit word read > but somewhere along the way, the top 24 bits are discarded. >=20 > The real interesting question is what happens when you do a byte > access at address 1. I think most devices simply don't allow that. >=20 >> then you can distinguish a BE device from an LE one. >> (Most notably, RAM in QEMU is always host-endian...) >> Devices which only allow 32 bit reads and abort any others wouldn't >> have an endianness though. >=20 > My guess is that if you do this with a PCI device we have marked as > LE, you'll get a truncated 32-bit read which will make it appear LE. > But that doesn't mean it's LE. >=20 >> (I need to sit down and think about this all and draw diagrams >> and look at what we currently do, though. BE guests on LE hosts >> with and without KVM look particularly thorny.) >=20 > I took a first pass at cleaning this up and broke PPC so I'm > investigating it further. There may be another layer of silliness > hidden somewhere too. Sorry for sending out invitations and then being late to this party - vacation. What is the status now? Do we have a short-term plan to avoid the regression or is this better solved by cleaning up the whole endianess thing? Is anyone actively on it, or should I take a drink, sit down and join the discussion? Jan ------enig2ABHNQETTOURDSLWCGKVD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHk88EACgkQitSsb3rl5xRLawCdHtxQVHGixGqWTYmTIZSK+oNN SVMAn0N+dGAkxb563lGMEmgfN6YtGV6U =2Li0 -----END PGP SIGNATURE----- ------enig2ABHNQETTOURDSLWCGKVD--