From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiJ5L-000590-Ty for qemu-devel@nongnu.org; Thu, 08 May 2014 03:49:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WiJ57-0001qb-0P for qemu-devel@nongnu.org; Thu, 08 May 2014 03:49:43 -0400 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:38161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiJ56-0001qF-O3 for qemu-devel@nongnu.org; Thu, 08 May 2014 03:49:28 -0400 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 May 2014 08:49:27 +0100 Date: Thu, 8 May 2014 09:49:18 +0200 From: Greg Kurz Message-ID: <20140508094918.77d1dec0@bahia.local> In-Reply-To: <536A9D72.7030309@gmail.com> References: <20140505074816.25523.71374.stgit@bahia.local> <20140505080438.25523.94922.stgit@bahia.local> <53677043.5000606@suse.de> <20140507102037.72d76d56@bahia.local> <536A8336.2000500@gmail.com> <536A9D72.7030309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Musta Cc: peter.maydell@linaro.org, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, afaerber@suse.de On Wed, 07 May 2014 15:54:10 -0500 Tom Musta wrote: > On 5/7/2014 2:02 PM, Tom Musta wrote: > > > It feels like there is an endianness issue here but I have not yet been able > > to put my finger on it. > > OK ... after more thought and scribbling ... here is what I mean .... > > Suppose I have a 64-bit value 0xa0a1a2a3a4a5a6a7 stored in guest memory and it > gets loaded into a GPR. If I follow the dump code and view all four combinations > of guest/host big/little endian, I convince myself that the big endian guest > code writes the byte sequence 0xa0, 0xa1, 0xa2, ..., 0xa7 into the file. And > the little endian guest dumps contain the sequence 0xa7, 0xa6, ..., 0xa0. > > This make sense ... the endianness indicated in the dump header and the endianness of > the dump file layout are consistent, irrespective of the host endianness. > > If I take this a step further and consider a 128-bit value 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf > stored in guest memory and look at the AVR structure (via printf or debugger) after doing > a 128-bit lvx load, I get the following: > > +------+-------+------------------+------------------+---------------------+ > | Host | Guest | avr.u64[0] | avr.u64[1] | file sequence | > +------+-------+------------------+------------------+---------------------+ > | BE | BE | a0a1a2a3a4a5a6a7 | a8a9aaabacadaeaf | a0,...,a7,a8,...,af | > | LE | BE | a8a9aaabacadaeaf | a0a1a2a3a4a5a6a7 | a8,...,af,a0,...,a7 | > | BE | LE | a0a1a2a3a4a5a6a7 | a8a9aaabacadaeaf | a7,...,a0,af,...,a8 | > | LE | LE | a8a9aaabacadaeaf | a0a1a2a3a4a5a6a7 | af,...,a8,a7,...,a0 | > +------+-------+------------------+------------------+---------------------+ > > The last column represents how I think the proposed dump code will write bytes > to disk. Notice that if you invert the (64-bit) array elements, then the two > BE dumps look alike and the two LE dumps look alike. If you swap array u64 > elements on LE hosts, and also swap on LE guests, then you get a byte sequence > that looks like a 128-bit integer in all cases. > > Then we already have an issue with the current code... -- Gregory Kurz kurzgreg@fr.ibm.com gkurz@linux.vnet.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)562 165 496 "Anarchy is about taking complete responsibility for yourself." Alan Moore.