From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btlpj-00033y-R7 for qemu-devel@nongnu.org; Mon, 10 Oct 2016 21:26:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btlph-0007IX-1b for qemu-devel@nongnu.org; Mon, 10 Oct 2016 21:26:18 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:40439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btlpf-0007HJ-Tk for qemu-devel@nongnu.org; Mon, 10 Oct 2016 21:26:16 -0400 Date: Tue, 11 Oct 2016 12:24:29 +1100 From: David Gibson Message-ID: <20161011012429.GA8952@umbus.fritz.box> References: <1475835267-7300-1-git-send-email-lvivier@redhat.com> <20161007124849.7c867d79@bahia> <20161010045552.GC22498@umbus.fritz.box> <20161010133954.GJ22498@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2] qtest: ask endianness of the target in qtest_init() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Greg Kurz , Laurent Vivier , QEMU Developers --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2016 at 03:10:33PM +0100, Peter Maydell wrote: > On 10 October 2016 at 14:39, David Gibson w= rote: > > In the overwhelming majority of cases the endianness of the device is > > known independent of the guest CPU and board. >=20 > We don't seem to model things that way: >=20 > $ git grep '.endianness =3D DEVICE_NATIVE' |wc -l > 341 > $ git grep '.endianness =3D DEVICE_BIG' |wc -l > 18 > $ git grep '.endianness =3D 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 =09 CRIS hw/cris 2 hw/*/etraxfs* 3 --- TOTAL 5 LM32 hw/*/milkymist* 10 hw/*/lm32* 2 --- TOTAL 12 =20 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 =09 XTENSA hw/xtensa 3 =3D=3D=3D 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. --=20 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 --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX/D9LAAoJEGw4ysog2bOSw3IQANjSWzd/9GhKvV9v8SESL90l 4lDny+Rj3oO5BYntwBDsopsIY68jySdLL1/iA058LyZV0oMviSkUR07h2npGMMJN tgOy7AWh3wPyWJxoPukpLX3TLxR5X+zsxjvAJI1vBYKKAEVRpjjxRGk7s+g8Xg96 4zAbP9ZjMa98mAaeG/xWuQvHqOWaSGR1uqxnRErE61UuSJh4vYq0JRV6vPCBZK6B F3fHdcKWnNsz2nns+G7GjQd2SVBOyQ28Bsq7e8DCNvts6xdnuaMMaKx/v5jQV8Bo 3+OcNlqIzXy6O8IMe7UOhNm52h44rdaJjjlyCsjb23JUVe4yiJpQNNXNmu0thbMB 8aX7rpZfr4ifv1PFRm/+UvEZwbWk/BNnvaF5dpHbu/IDhs41Q2hPAIGKOfCPEDwe crKTET/i/9y5q2StW8meGElzECjI7F/mepf+YQLxy36yN+0+NE+hzQFx23+PONed 1Nm9vFdSmoe75N5V5RtnNLYc1kxRAO+AZIVYsrL6SMr8Ba1AeL/mfRRHXxp2tsPp XBpI5THaLwgOWb29FNCgNOhUp+zyZZDIPUlPdf2ZxEwYadAY1/r4WZBupxcVMzg5 XcJEPD6UE9ovq7ds/4agG5kMdH8WqGDKRCjE4xKE4GrBBGUUYyO+1F93jIKcceJS JdnvAdNj8FnyG/5a5CNQ =H24F -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C--