On 8 August 2013 17:25, Anthony Liguori <anth...@codemonkey.ws> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: >> On 8 August 2013 17:07, Anthony Liguori <anth...@codemonkey.ws> wrote: >>> CPU data structures are still read as big endian though. >> >> Do you have an example of what you mean by "CPU data structure"? > > MMU tlb hash table. If you grep ldl target-ppc/* you'll see that there > are only a few cases where bswap occurs.
Oh, right, that sort of in-memory data structure. If I understand correctly, the equivalent of that for ARM would be the MMU translation tables; on ARM there's a system control register bit for which endianness those are. >> Any stl_phys() should [in an ideal design] be tied to a >> "bus master" which has its own idea of which endianness >> it is. That is, an stl_phys() for a DMA controller model >> ought to use the endianness programmed for the DMA controller, >> not whatever the CPU happens to be using. > > We have the DMA API that attempts to do this but maybe we need to > generalize it a bit more... > > I think it's pretty true that we need a context and that the context > for, say instruction fetch, is distinct from the context for load/store > instructions. A context might also give us a place to put other interesting information which in hardware gets passed around as transaction attributes on the bus, such as "is this a userspace or privileged instruction". -- PMM
