From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59350)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WkJOY-0003Gl-Ro
	for qemu-devel@nongnu.org; Tue, 13 May 2014 16:33:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WkJOP-0007SB-R0
	for qemu-devel@nongnu.org; Tue, 13 May 2014 16:33:50 -0400
Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:63182)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WkJOP-0007S4-Ku
	for qemu-devel@nongnu.org; Tue, 13 May 2014 16:33:41 -0400
Received: by mail-ee0-f45.google.com with SMTP id d49so764058eek.4
	for <qemu-devel@nongnu.org>; Tue, 13 May 2014 13:33:40 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <5372819F.30908@redhat.com>
Date: Tue, 13 May 2014 22:33:35 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1400005030-20729-1-git-send-email-somlo@cmu.edu>	<1400005030-20729-2-git-send-email-somlo@cmu.edu>	<53727C09.1010208@redhat.com>
	<20140513202115.GO30030@ERROL.INI.CMU.EDU>
In-Reply-To: <20140513202115.GO30030@ERROL.INI.CMU.EDU>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 1/2] SMBIOS: Fix endian-ness when
 populating fields wider than 8-bit
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: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: lersek@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com

Il 13/05/2014 22:21, Gabriel L. Somlo ha scritto:
>>> > >-    t->processor_id[0] = smbios_cpuid_version;
>>> > >-    t->processor_id[1] = smbios_cpuid_features;
>>> > >+    t->processor_id[0] = smbios_cpuid_version; /* opaque, no cpu_to_le16 */
>>> > >+    t->processor_id[1] = smbios_cpuid_features; /* opaque, no cpu_to_le16 */
>> >
>> > Actually I think these should be subject to cpu_to_le32.  They
>> > correspond to CPUID values, so they are little-endian 32-bit.
> Right, my comment is wrong, should be "no need for cpu_to_le32()" instead
> of what I said ("no need for cpu_to_le16()")... :)
>
> Re. why I said "opaque, no need for endianness fix" is because they're
> a straight-through assignment from cpu->env.cpuid_version and
> cpu->env.features[FEAT_1_EDX], respectively. So they're not really
> "numbers" which need endianness adjustment.
>
> Did I get that wrong ? (I mean, besides the 16 vs. 32 in the comment) ?

I think they do need cpu_to_le32.  We assign them straight from other 
32-bit integers, but still bits 0..7 should be in byte 0, bits 8..15 
should be in byte 1, etc.  So we need to convert from host CPU 
endianness to target CPU endianness.

Paolo