as suggested in the comment.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/net/eepro100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index 61d767524f..abb44710d9 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -266,7 +266,7 @@ typedef struct {
 
     /* Data in mem is always in the byte order of the controller (le).
      * It must be dword aligned to allow direct access to 32 bit values. */
-    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(8);
+    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(4);
 
     /* Configuration bytes. */
     uint8_t configuration[22];
-- 
2.15.1

On 08/01/2018 19:02, Philippe Mathieu-Daudé wrote:
>      /* Data in mem is always in the byte order of the controller (le).
>       * It must be dword aligned to allow direct access to 32 bit values. */
> -    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(8);
> +    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(4);

It's actually not needed at all, since accesses go through ld*_le_p and
st*_le_p (commit 4d9be25, "hw/net/eepro100.c: Don't use cpu_to_*w() and
*_to_cpup()", 2016-06-16).

Paolo

On 01/08/2018 03:10 PM, Paolo Bonzini wrote:
> On 08/01/2018 19:02, Philippe Mathieu-Daudé wrote:
>>      /* Data in mem is always in the byte order of the controller (le).
>>       * It must be dword aligned to allow direct access to 32 bit values. */
>> -    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(8);
>> +    uint8_t mem[PCI_MEM_SIZE] QEMU_ALIGNED(4);
> 
> It's actually not needed at all, since accesses go through ld*_le_p and
> st*_le_p (commit 4d9be25, "hw/net/eepro100.c: Don't use cpu_to_*w() and
> *_to_cpup()", 2016-06-16).

Cool, I'll update this.

Thank you,

Phil.