[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qtest tmp105-test endianness issue
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] qtest tmp105-test endianness issue |
Date: |
Sat, 26 Jan 2013 23:51:46 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 |
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.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg