On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote: > On 10 October 2016 at 14:39, David Gibson <da...@gibson.dropbear.id.au> wrote: > > In the overwhelming majority of cases the endianness of the device is > > known independent of the guest CPU and board. > > We don't seem to model things that way: > > $ git grep '.endianness = DEVICE_NATIVE' |wc -l > 341 > $ git grep '.endianness = DEVICE_BIG' |wc -l > 18 > $ git grep '.endianness = DEVICE_LITTLE' |wc -l > 172
Sigh. So, most of these are themselves mistakes.
A lot of these are target specific devices that should be tagged with
their target's (notional) endianness, rather than NATIVE. That
covers:
ARM
hw/arm 68
hw/*/bcm283* 8
hw/*/imx* 13
hw/*/omap* 27
hw/*/pl* 10
hw/*/exynos* 8
hw/net/lan9118.c 2
hw/*/pxa2xx* 8
hw/gpio/zaurus.c 1
hw/*/versatile* 3
hw/*/allwinner* 3
hw/*/arm* 15
hw/*/a9* 3
hw/char/cadence* 2
hw/*/digic* 2
hw/*/stm32f2xx* 5
hw/usb/tusb6010.c 1
hw/misc/mst_fpga.c 1
hw/net/smc91c111.c 1
hw/net/stellaris_enet.c 1
hw/misc/zynq* 2
hw/dma/xlnx_dpdma.c 1
hw/display/xlnx_dp.c 4
hw/ssi/xilinx_spips.c 1
hw/display/tc6393xb.c 1
hw/audio/marvell_88w8618.c 1
hw/block/onenand.c 1
---
TOTAL 193
CRIS
hw/cris 2
hw/*/etraxfs* 3
---
TOTAL 5
LM32
hw/*/milkymist* 10
hw/*/lm32* 2
---
TOTAL 12
M68K
hw/m68k 4
hw/*/mcf* 2
---
TOTAL 6
MICROBLAZE
hw/dma/xilinx_axidma.c 1
hw/char/xilinx_uartlite.c 1
hw/intc/xilinx_intc.c 1
hw/net/xilinx_ethlite.c 1
hw/timer/xilinx_timer.c 1
hw/ssi/xilinx_spi.c 1
---
TOTAL 6
MIPS
hw/mips 8
hw/*/mips* 5
hw/display/jazz_led.c 1
hw/dma/rc4030.c 2
hw/net/dp8393x.c 1
hw/pci-host/bonito.c 5
---
TOTAL 22
OPENRISC
hw/openrisc 1
PPC
hw/ppc 7
hw/char/escc.c 1
hw/ide/macio.c 1
hw/misc/macio/cuda.c 1
hw/misc/applesmc.c 2
hw/net/fsl_etsec/etsec.c 1
---
TOTAL 13
SH
hw/sh4 4
hw/*/sh_* 3
hw/display/sm501.c 4
---
TOTAL 11
SPARC
hw/*/grlib* 3
hw/*/slavio* 11
hw/dma/sparc32_dma.c 1
hw/dma/sun4m_iommu.c 1
hw/display/tcx.c 7
hw/pci-host/apb.c 2
hw/misc/eccmemctl.c 2
hw/display/cg3.c 1
hw/audio/cs4231.c 1
---
TOTAL 29
UNICORE32
hw/*/puv3* 5
X86
hw/i386 9
hw/pci-host/q35.c 1
hw/timer/hpet.c 1
---
TOTAL 11
XTENSA
hw/xtensa 3
===
OVERALL TOTAL 317
There are some PCI devices, where AFAICT, the NATIVE_ENDIAN tag is
Just Plain Wrong (i.e. I believe these devices will be broken on BE
targets):
hw/scsi/lsi53c895a.c 3
hw/ipack/tpci200.c 5
hw/misc/edu.c 1
hw/audio/intel-hda.c 1
hw/pci/pcie_host.c 1
And there are some devices which only accept 1 byte accesses, so the
endianness is irrelevant anyway:
hw/block/fdc.c 2
hw/dma/i8257.c 2
hw/isa/vt82c686.c 1
There are ISA devices. I'd expect these to be always-LE, but I'm not
sure exactly how they're handled. In wonder if they've been tested on
BE.
hw/char/parallel.c 1
hw/input/pckbd.c 1
hw/display/vga-isa-mm.c 1
Then there are some which are part of the MR infrastructure, rather
than a device itself:
exec.c 8
ioport.c 1
memory.c 1
include/exec/cpu-common.h 1
hw/core/empty_slot.c 1
What does that leave..
hw/block/pflash_cfi01.c 1
hw/block/pflash_cfi02.c 2
These appear to have its own internal endianness handling
hw/char/serial.c 2
hw/timer/m48t59.c 1
These are "raw" MMIO devices which are common enough that they do
exist in the wild with weird wiring variations. These were always
going to require some special casing.
hw/intc/apic.c 1
hw/intc/ioapic.c 1
All the platforms which have APIC (x86 & arm) are notionally LE. I
imagine it would break if you tried to attach it to a BE platform.
hw/net/lance.c 1
This is the backend of the old PC-Net driver. I suspect the "wrapper"
layers by which it's usually used may fix the endianness. Or possibly
it's just broken on BE.
hw/scsi/esp.c 1
The platforms it appears on (MIPS Jazz & sun4m) are both notionally
BE. I imagine it would break if you tried to attach it to an LE
platform.
And finally
hw/misc/ivshmem.c 1
hw/virtio/virtio-mmio.c 1
hw/xen/xen_pt* 2
virtio has been discussed before. The others are also purely virtual
devices, which I suspect have made the same design error as old
virtio. However I don't think any BE platforms use ivshmem or xen in
practice, so they could be considered always-LE.
So, yeah, I still think "overwhelming majority" is accurate.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
