[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PULL for-2.0 2/7] raven: Implement non-contiguous I/O re

From: Peter Maydell
Subject: Re: [Qemu-ppc] [PULL for-2.0 2/7] raven: Implement non-contiguous I/O region
Date: Tue, 8 Apr 2014 21:56:38 +0100

On 8 April 2014 21:27, Paolo Bonzini <address@hidden> wrote:
> I agree, and in fact we should also use DEVICE_NATIVE_ENDIAN less, not more.
> Unfortunately, forwarding accesses from one address space to another via
> MMIO accessors requires DEVICE_NATIVE_ENDIAN, and that in turn requires
> target-endianness ldl_p/stl_p.

I don't think this is correct. If we're purely forwarding
then you can just use DEVICE_LITTLE_ENDIAN and ldl_le_p.
There are three places in the sequence of calls from CPU to
outer MMIO accessor to stl_le_p to memory_space_write
that might insert bswaps:
 1 before the call to the outer MMIO accessor we will bswap
   if the guest endianness is not LE (because we're calling an
   MMIO accessor that was marked DEVICE_LITTLE_ENDIAN)
 2 in the stl_le_p we will bswap if the host endianness is not LE
   (because that's what stl_le_p means)
 3 in memory_space_write when we read out of the buffer we
   do a ldl_q, which will bswap if the host endianness is not
   the target endianness (because we get the cpu-all.h version
   of ldl_q, which does a target-endian load)

host = guest = LE: no swapping
host = LE, guest = BE: swap 1 and 3 active
host = BE, guest = LE: swap 2 and 3 active
host = guest = BE: swap 1 and 2 active

In all cases we do an even number of swaps and the whole thing
cancels out :-)

You can use DEVICE_BIG_ENDIAN and stl_be_p if you like,
for equivalent effect.

I'm pretty sure this wasn't an intentional design property, though...

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]