[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
Re: [Qemu-devel] [PATCH v2 1/2] SMBIOS: Fix endian-ness when populating fields wider than 8-bit
Tue, 13 May 2014 22:33:35 +0200
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 = smbios_cpuid_version;
> >- t->processor_id = smbios_cpuid_features;
> >+ t->processor_id = smbios_cpuid_version; /* opaque, no cpu_to_le16 */
> >+ t->processor_id = 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.
[Qemu-devel] [PATCH v2 2/2] SMBIOS: Update Type 0 struct generator for machines >= 2.1, Gabriel L. Somlo, 2014/05/13