Am 26.01.2013 um 23:51 schrieb Andreas Färber <afaer...@suse.de>:
> 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. Oh, I'm sure the bug exists. What I'msaying is that nothing _should_ convert endianness. Alex > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
