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
