qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <gkurz@linux.vnet.ibm.com>
To: Tom Musta <tommusta@gmail.com>
Cc: peter.maydell@linaro.org, Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	bharata@linux.vnet.ibm.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64
Date: Thu, 8 May 2014 09:49:18 +0200	[thread overview]
Message-ID: <20140508094918.77d1dec0@bahia.local> (raw)
In-Reply-To: <536A9D72.7030309@gmail.com>

On Wed, 07 May 2014 15:54:10 -0500
Tom Musta <tommusta@gmail.com> 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.

  parent reply	other threads:[~2014-05-08  7:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05  8:02 [Qemu-devel] [PATCH v3 0/4] little-endian dump for ppc64 Greg Kurz
2014-05-05  8:04 ` [Qemu-devel] [PATCH v3 1/4] dump: Make DumpState and endian conversion routines available for arch-specific dump code Greg Kurz
2014-05-05  8:05 ` [Qemu-devel] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64 Greg Kurz
2014-05-05 11:04   ` Alexander Graf
2014-05-07  8:20     ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2014-05-07 19:02       ` Tom Musta
2014-05-07 20:54         ` Tom Musta
2014-05-07 20:59           ` Alexander Graf
2014-05-08  7:49           ` Greg Kurz [this message]
2014-05-05  8:07 ` [Qemu-devel] [PATCH v3 3/4] target-ppc: ppc can be either endian Greg Kurz
2014-05-06 18:37   ` Peter Maydell
2014-05-07  8:14     ` Greg Kurz
2014-05-07  9:06       ` Peter Maydell
2014-05-07  9:09       ` Alexander Graf
2014-05-07  9:26         ` Peter Maydell
2014-05-07  9:37           ` Alexander Graf
2014-05-07  9:40             ` Peter Maydell
2014-05-07  9:44               ` Alexander Graf
2014-05-07  9:41           ` Alexander Graf
2014-05-07 10:19             ` Greg Kurz
2014-05-07 11:54               ` Alexander Graf
2014-05-07 12:40                 ` Greg Kurz
2014-05-07 13:04                   ` Alexander Graf
2014-05-08  1:36                 ` Rusty Russell
2014-05-05  8:07 ` [Qemu-devel] [PATCH v2 4/4] ppc64 dump: Set the correct endianness in ELF dump header Greg Kurz
2014-05-05 11:08 ` [Qemu-devel] [PATCH v3 0/4] little-endian dump for ppc64 Alexander Graf
2014-05-07 21:14 ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140508094918.77d1dec0@bahia.local \
    --to=gkurz@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=tommusta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).