Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer

[Peter Maydell]

On 15 July 2013 15:01, Anthony Liguori <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> On 12 July 2013 23:50, Benjamin Herrenschmidt <address@hidden> wrote:
>> I agree that TARGET_WORDS_BIGENDIAN *should* go away, but
>> it exists currently. Do you actually implement a CPU which
>> does dynamic endianness flipping?
>
> TCG already supports bi-endianness for PPC.  Grep for 'le_mode' in
> target-ppc/translate.c to see how the TCG instruction stream is affected
> by it.

Right, that's what I thought. This means that if you're on a
little-endian host and using a PPC chip in le-mode then the
QEMU infrastructure will byteswap the data, and then those
generated bswap* ops will byteswap it again. It would be more
efficient if we supported dynamically having the emulated
CPU specify whether it wanted a BE or LE memory access, and
then byteswapping the correct number of times based on
device/host endianness/CPU setting. (This would also avoid
ugliness like the current ARM BE8 code which should be doing
"BE read for data, LE read for instructions" and instead has
to do "BE read of everything via TARGET_WORDS_BIGENDIAN
and then swap the instruction words again to get back to LE".)
If we ever want to support multiple different CPUs in one
model we'll need this anyway, because one might be BE and
another LE.

> On PPC, le_mode only really affects load/stores and instruction
> decoding.  Any shared data structures between the CPU and OS remain big
> endian.
>
> So TARGET_WORDS_BIGENDIAN is still accurate even when
> le_mode=1.  It's not the semantic equivalent of
> changing TARGET_WORDS.

I'm not sure what you mean by "accurate" here. It's a compile
time switch, when the hardware we're actually emulating does
runtime (dynamic) switching, and when the current runtime
mode doesn't match the compiled-in setting we end up doing
unnecessary double-swap operations.

thanks
-- PMM