Re: [Qemu-devel] [Qemu-ppc] [PATCH 16/16] target-ppc: Convert to new ldst opcodes

[Alexander Graf]

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: address@hidden
>>> Signed-off-by: Richard Henderson <address@hidden>
>> 
>> 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