qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH for-2.11] hw/net/eepro100: Fix endianness proble


From: Stefan Weil
Subject: Re: [qemu-s390x] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts
Date: Fri, 17 Nov 2017 06:35:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Am 17.11.2017 um 05:14 schrieb Michael S. Tsirkin:
> On Thu, Nov 16, 2017 at 10:16:54PM +0100, Thomas Huth wrote:
>> Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
>> mode"), the test/pxe-test is broken for the eepro100 device on big
>> endian hosts. However, it seems like that commit did not introduce the
>> problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
>> EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
>> they have already been byte-swapped in the read_cb() function.
>> Thus byte-swapping them in tx_command() again results in the wrong
>> endianness. Removing the byte-swapping here fixes the pxe-test.
>>
>> Signed-off-by: Thomas Huth <address@hidden>
> 
> 
> Reviewed-by: Michael S. Tsirkin <address@hidden>
> 
> Thomas, how about adding sparse endian-ness annotations
> a la le32 in Linux? We could then use static checkers to
> catch these bugs at build time.

My main problem is that running big endian tests are
much more complex and time consuming simply because
my only big endian machines are QEMU virtual machines
(PPC* or MIPS*), so a test requires running QEMU
inside QEMU.

Nevertheless I had run such tests with network boot
and Linux guests as test cases, and they worked
(see comments in the header of eepro100.c).

So I wonder how the tests have to be enhanced to cover
more cases.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]