Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio

[Blue Swirl]

On Fri, Nov 26, 2010 at 11:47 PM, Paul Brook <address@hidden> wrote:
>> > diff --git a/exec.c b/exec.c
>> > index db9ff55..f54a360 100644
>> > --- a/exec.c
>> > +++ b/exec.c
>> >
>> > @@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int
>> > io_index,
>> >
>> >     }
>> >     io_mem_opaque[io_index] = opaque;
>> >
>> > +    switch (endian) {
>> > +    case DEVICE_BIG_ENDIAN:
>> > +#ifndef TARGET_WORDS_BIGENDIAN
>> > +        swapendian_init(io_index);
>> > +#endif
>> > +        break;
>>
>> So basically, you just moved the #ifdefs to another place. :)
>
> Many #ifdefs inconsistently scattered through all the device code have been
> replaced by a single #ifdef.
>
>> Shouldn't this be dependent on the CPU state and determined at
>> runtime? Thinking of MSR LE bit on ppc. I guess QEMU doesn't support
>> bi-endian ppc today, as does the 970, but it would be nice to keep it
>> in mind.
>
> Switching endianness of a CPU generally does not effect the endianness of the
> CPU/peripheral busses.  It makes the CPU byteswap accesses before they are
> seen by either memory or devices.
>
> In theory it might be possible to avoid redundant byteswaps if you're really
> clever.  In practice you still have to handle the fact that your devices are a
> different endianness to RAM, so it probably doesn't gain you a whole lot.

Sparc64 MMU can also perform byte swapping, there is also a byte
swapping CPU mode and byte swapping access instructions. I think only
the instructions are used (for PCI).