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

[Paolo Bonzini]

Il 08/04/2014 14:55, Peter Maydell ha scritto:
> On 8 April 2014 19:39, Paolo Bonzini <address@hidden> wrote:
> > So the fix could be to compile prep.c per-target (and change to
> > DEVICE_NATIVE_ENDIAN too).
>
> That seems like the wrong direction -- we should be
> making fewer files per-target, not more.

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.

We could to try and make the non-contiguous I/O region an IOMMU region, 
if that can work.  But that would be post-2.0, I think.

I'm of course assuming that we cannot just revert patch 2 in this series...

> > > Worse, we have two versions of the ldl_p()/stl_p() &c
> > > functions with conflicting semantics!
> > > cpu-all.h defines these to be "target CPU endianness".
> > > bswap.h defines these to be "host CPU endianness".
>
> > Ouch!  I have some cleanups for CPU ld/st ready for 2.1, I'll add a patch to
> > rename bswap.h's definition to ldl_host_p/stl_host_p.
>
> Richard's suggestion was to make the cpu-all.h ones
> be ldl_te_p/stl_te_p, which I think I like better.
> We could do both in order to enforce that we audited
> everything to see which it thought it was :-)

Yes, that's the next obvious step.

Paolo