[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v3 2/4] ppc64-dump: Support dump for little endian
From: |
Greg Kurz |
Subject: |
Re: [Qemu-ppc] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64 |
Date: |
Thu, 8 May 2014 09:49:18 +0200 |
On Wed, 07 May 2014 15:54:10 -0500
Tom Musta <address@hidden> 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 address@hidden
address@hidden
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)562 165 496
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
[Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Greg Kurz, 2014/05/05
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Peter Maydell, 2014/05/06
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Greg Kurz, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Peter Maydell, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Alexander Graf, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Peter Maydell, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Alexander Graf, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Peter Maydell, 2014/05/07
- Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Alexander Graf, 2014/05/07
Re: [Qemu-ppc] [PATCH v3 3/4] target-ppc: ppc can be either endian, Alexander Graf, 2014/05/07