From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38741)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <tommusta@gmail.com>) id 1Wi76o-00078s-8P
	for qemu-devel@nongnu.org; Wed, 07 May 2014 15:02:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <tommusta@gmail.com>) id 1Wi76i-0001wl-If
	for qemu-devel@nongnu.org; Wed, 07 May 2014 15:02:26 -0400
Message-ID: <536A8336.2000500@gmail.com>
Date: Wed, 07 May 2014 14:02:14 -0500
From: Tom Musta <tommusta@gmail.com>
MIME-Version: 1.0
References: <20140505074816.25523.71374.stgit@bahia.local>	<20140505080438.25523.94922.stgit@bahia.local>	<53677043.5000606@suse.de>
	<20140507102037.72d76d56@bahia.local>
In-Reply-To: <20140507102037.72d76d56@bahia.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 2/4] ppc64-dump: Support dump
 for little endian ppc64
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>, Alexander Graf <agraf@suse.de>
Cc: peter.maydell@linaro.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, afaerber@suse.de, bharata@linux.vnet.ibm.com

On 5/7/2014 3:20 AM, Greg Kurz wrote:
> On Mon, 05 May 2014 13:04:35 +0200
> Alexander Graf <agraf@suse.de> wrote:
>> On 05/05/2014 10:05 AM, Greg Kurz wrote:
>>> From: Bharata B Rao <bharata@linux.vnet.ibm.com>
>>>
>>> Fix ppc64 arch specific dump code to work correctly for little endian
>>> guests.
>>>
>>> We introduce a NoteFuncArg type to avoid adding extra arguments to all note
>>> functions.
>>>
>>> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
[snip]

>>> -static void ppc64_write_elf64_vmxregset(Note *note, PowerPCCPU *cpu)
>>> +static void ppc64_write_elf64_vmxregset(NoteFuncArg *arg, PowerPCCPU *cpu)
>>>   {
>>>       int i;
>>>       struct PPC64ElfVmxregset *vmxregset;
>>> +    Note *note = &arg->note;
>>> +    DumpState *s = arg->state;
>>>   
>>> -    note->hdr.n_type = cpu_to_be32(NT_PPC_VMX);
>>> +    note->hdr.n_type = cpu_to_dump32(s, NT_PPC_VMX);
>>>       vmxregset = &note->contents.vmxregset;
>>>       memset(vmxregset, 0, sizeof(*vmxregset));
>>>   
>>>       for (i = 0; i < 32; i++) {
>>> -        vmxregset->avr[i].u64[0] = cpu_to_be64(cpu->env.avr[i].u64[0]);
>>> -        vmxregset->avr[i].u64[1] = cpu_to_be64(cpu->env.avr[i].u64[1]);
>>> +        vmxregset->avr[i].u64[0] = cpu_to_dump64(s, cpu->env.avr[i].u64[0]);
>>> +        vmxregset->avr[i].u64[1] = cpu_to_dump64(s, cpu->env.avr[i].u64[1]);
>>
>> Is this correct? Tom, could you please ack if it is?
>>
>>
>> Alex
>>
>>
> 
> Tom,
> 
> Can you comment plz ?
> 
> Thanks.
> 

Is the avr element in the dump supposed to represent a 128-bit value?

Or maybe I should ask a more fundamental question:  should a dump of a BE guest
be identical regardless of whether it is a BE host or LE host.  Ditto for an
LE guest.

It feels like there is an endianness issue here but I have not yet been able
to put my finger on it.