[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: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PULL for-2.0 2/7] raven: Implement non-contiguous I/O region
Date: Tue, 08 Apr 2014 16:27:58 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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

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.


reply via email to

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