Re: [Qemu-ppc] qtest tmp105-test endianness issue

[Blue Swirl]

On Sat, Jan 26, 2013 at 10:51 PM, Andreas Färber <address@hidden> wrote:
> Am 26.01.2013 23:21, schrieb Alexander Graf:
>>
>> On 26.01.2013, at 23:12, Andreas Färber wrote:
>>
>>> I've found that my tmp105-test fails on Mac OS X ppc(64), i.e. Little
>>> Endian arm-softmmu target and Big Endian host:
>>>
>>> GTESTER check-qtest-arm
>>> mipid_reset: Display off
>>> **
>>> ERROR:/Users/andreas/QEMU/qemu/tests/libi2c-imap.c:163:omap_i2c_create:
>>> assertion failed (data == 0x34): (0x00003400 == 0x00000034)
>>>
>>> The only other test case that uses memread() is m48t59-test, which uses
>>> size 1 MMIO accesses only. This suggests that Big Endian guest (e.g.,
>>> sparc) and Little Endian host (e.g., x86_64) may cause issues, too.
>>>
>>> What is the expected way to handle endianness in qtest? Should
>>> qtest.c:qtest_process_command() be changed? libqtest.c:qtest_memread()?
>>> Or the test itself byteswap and, if so, under which circumstances?
>>
>> Well, first of all qtest works on behalf of the emulated CPU. The MMIO code 
>> path doesn't care about target CPU endianness. It simply passes the "native" 
>> value to the handler. The handler however might change byte order depending 
>> on the memory api endianness flag.
>>
>> But in this particular case, I'd be very surprised if any endianness 
>> swapping had to be involved.
>
> Fact is, it passes on x86 and fails on ppc. :)
> Reproducible on openSUSE ppc64.

It also fails on Sparc64. But other tests (x86 and Sparc) are fine,
except (maybe because of lack of memory or slow NFS) /dicts/large_dict
in tests/check-qjson does not finish in reasonable time.

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg