qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] SMBIOS: Fix endian-ness when populating


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [PATCH v2 1/2] SMBIOS: Fix endian-ness when populating fields wider than 8-bit
Date: Tue, 13 May 2014 16:46:43 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, May 13, 2014 at 10:33:35PM +0200, Paolo Bonzini wrote:
> 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.

OK, so the host creates cpu->env.cpuid_version and
cpu->env.features[FEAT_1_EDX] in *host* format, so on
a BE host the i386 cpu values would be in BE ordrer,
and so I'd have to convert them to LE on behalf of the
x86 guest ?

OK, I'll go ahead and do that, then :)

Thanks!

--Gabriel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]