ladr_match can cause bus error due to unaligned fetch

Host environment

• Operating system: Solaris 11
• OS/kernel version: 11.4.42.111.0 sun4v sparc
• Architecture: SPARC
• QEMU flavor: qemu-system-sparc
• QEMU version: 8.2.50 (v8.2.0-887-g11be7067-dirty)
• QEMU command line:

./qemu-system-sparc \
    -rtc base=utc,clock=host \
    -vga cg3 \
    -g 1024x768x8 \
    -machine SS-5 \
    -cpu "TI MicroSparc I" \
    -m 64 \
    -bios ss5.bin \
    -prom-env 'setenv auto-boot?=false' \
    -drive file=sunos-hdd-nhb.img,bus=0,unit=3,media=disk \
    -device scsi-cd,scsi-id=6,drive=cd0,physical_block_size=512 \
    -drive if=none,file=Solaris1.1.2-SunOS4.1.4.iso,format=raw,media=disk,id=cd0

Emulated/Virtualized environment

• Operating system: SunOS
• OS/kernel version: SunOS 4.1.4/Solaris 1.1.2
• Architecture: SPARC

Description of problem

On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match.

Steps to reproduce

1. (see QEMU command line above)
2. let the system boot

Additional information

Problem is a hack in ladr_match - hw/net/pcnet.c:635 (present since 2006!):

Core was generated by `./qemu-system-sparc -rtc base=utc,clock=host -vga cg3 -g 1024x768x8 -machine SS'.
Program terminated with signal SIGKILL, Killed.
#0  0xffffffff7ec3b178 in ladr_match (size=110, buf=0xffffffff7ffee972 "33", s=0x808f2a20) at ../hw/net/pcnet.c:634
634         if ((*(hdr->ether_dhost)&0x01) &&
[Current thread is 632 (LWP    1        )]
(gdb) list
629     }
630     
631     static inline int ladr_match(PCNetState *s, const uint8_t *buf, int size)
632     {
633         struct qemu_ether_header *hdr = (void *)buf;
634         if ((*(hdr->ether_dhost)&0x01) &&
635             ((uint64_t *)&s->csr[8])[0] != 0LL) {
636             uint8_t ladr[8] = {
637                 s->csr[8] & 0xff, s->csr[8] >> 8,
638                 s->csr[9] & 0xff, s->csr[9] >> 8,
(gdb) print &s->csr[8]
$1 = (uint16_t *) 0x808f4a7c

The address of s->csr[8], in this case, is on a 4-byte boundary not an 8-byte boundary, so the hack to test for 8 bytes (4 x 16-bit words) being 0 by casting the address up to a pointer to uint64_t and dereferencing it fails.

The data does not seem to be allocated with a deterministic alignment, this failure does not always occur.

A solution to avoid alignment errors could be to test

  (s->csr[8] | s->csr[9] | s->csr[10] | s->csr[11]) != 0