Il 08/04/2014 14:55, Peter Maydell ha scritto:
On 8 April 2014 19:39, Paolo Bonzini <pbonz...@redhat.com> 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
