On Tue, Oct 11, 2016 at 12:24:29PM +1100, David Gibson wrote: > 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:
A couple of points of clarification here.
When I say the "device" endianness is known, that's a little sloppy.
I mean that the endianness of each specific register (or DMA field)
has a known endianness. The device as a whole does not have well
defined endianness except insofar as one device will generally use the
same endianness for all its >8bit registers and/or DMA fields.
There are a few exceptions of course. virtio-balloon (pre 1.0) on a
notionally BE platform is a horrible example: its PCI config space is
LE, the generic part of the virtio config space is BE ("native") and
the balloon specific part is LE again (due to a screwup in the spec).
Intermediate bridges in the system (on or off chip) won't affect this,
*as long as* they preserve byte address invariance. If they *don't*
preserve byte address invariance, then:
1) Shoot your HW designer
2) Grudgingly work around with special cases in your tests
--
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
