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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 1/2] SMBIOS: Fix endian-ness when populating fields wider than 8-bit
Date: Tue, 13 May 2014 22:33:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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



reply via email to

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