Re: [Qemu-devel] [PATCH v2] qtest: ask endianness of the target in qtest_init()

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 5374 bytes --]

On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote:
> On 10 October 2016 at 14:39, David Gibson <david@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]