On 05.09.2013, at 13:40, Benjamin Herrenschmidt wrote: > On Thu, 2013-09-05 at 11:08 +0200, Alexander Graf wrote: >> On 04.09.2013, at 23:05, Richard Henderson wrote: >> >>> This lets us change "le_mode" to "end_mode" and fold away nearly all >>> of the tests for the current cpu endianness, and removing all of the >>> explicitly generated bswap opcodes. > > Only nit: I find "end_mode" a very confusing identifier :-) "end" > usually means something else ! Why not endian_mode ? >>> >>> Cc: qemu-...@nongnu.org >>> Signed-off-by: Richard Henderson <r...@twiddle.net> >> >> No complaints from me, apart from the usual "LE mode isn't necessarily what >> you think it is on PPC" one. But the code would be as broken as before IIUC. >> >> Ben, you had some insight in how LE mode on different PPC flavors work. >> Could you please make sure we're not walking into the wrong direction here? > > I haven't seen the patch itself for some reason (and I'm about to go off > for a few days). The early day powerpc endian mode can be safely ignored > I think, I don't even remember the details myself, I think it induced > some changes to the byte lanes ordering on the bus and thus required the > host bridge to be adjusted. > > The embedded PPCs have simply a per-page E bit in the TLB controlling > the endianness of accesses through the translation, the endianness is > "clean" in that case, and the bus doesn't flip around so it's akin to > what P7 does but with a finer granularity.
So on P7 basically everything that goes from registers out is byte-swapped, including any RAM access and MMIOs? I think that's basically what the current little endian mode implements (though it might miss a few places, like FPU or Altivec, but I'd consider that bugs). Alex
