Peter Maydell peter.mayd...@linaro.org writes:
On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org
wrote:
Our experience is that it actually works fine for almost everything
except virtio :-) ie mostly TARGET_WORDS_BIGENDIAN is irrelevant (and
should be).
I agree that
On 15 July 2013 15:01, Anthony Liguori anth...@codemonkey.ws wrote:
Peter Maydell peter.mayd...@linaro.org writes:
On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org
wrote:
I agree that TARGET_WORDS_BIGENDIAN *should* go away, but
it exists currently. Do you actually
On Mon, 2013-07-15 at 09:01 -0500, Anthony Liguori wrote:
On PPC, le_mode only really affects load/stores and instruction
decoding. Any shared data structures between the CPU and OS remain big
endian.
Translation:
On ppc with the specific machine type pseries which emulates a
paravirtualized
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
We model a single system wide io space today and access to that one
happens through you pci host controller. I just messed up the
terminology here.
Single system wide IO space is broken. We have separate IO space per
PHB. That was
Benjamin Herrenschmidt a écrit :
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
We model a single system wide io space today and access to that one
happens through you pci host controller. I just messed up the
terminology here.
Single system wide IO space is broken. We have separate
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
We model a single system wide io space today and access to that one
happens through you pci host controller. I just messed up the
terminology here.
Single system wide IO space is
On 12 July 2013 18:49, Anthony Liguori anth...@codemonkey.ws wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
We model a single system wide io space today and access to that one
happens through you pci host controller. I
Hervé Poussineau hpous...@reactos.org writes:
When only one of them is changed, this means some interesting things
can happen. For example, in [1]:
When PowerPC little-endian is in effect but before system's
little-endian is in effect, the address munge becomes effective. If we
need to
On Fri, 2013-07-12 at 19:04 +0200, Hervé Poussineau wrote:
When PowerPC little-endian is in effect but before system's
little-endian is in effect, the address munge becomes effective. If we
need to access system endian port (byte) address, say 0x8092, the
program needs to issue
On Fri, 2013-07-12 at 12:49 -0500, Anthony Liguori wrote:
Unless they are completely broken (and those exist, don't get me wrong,
though mostly they are a thing of a past long gone), bridges and busses
have no effect on endianness.
That's simply not true. There are programmable PCI
On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote:
It's not wrong when the hardware actually does a byteswap at
some level in the memory hierarchy. You can see this for instance
on ARMv7M systems, where byteswapping for bigendian happens at
an intermediate level that not all accesses go
On Fri, 2013-07-12 at 14:06 -0500, Anthony Liguori wrote:
In the light of this, I think there should only be one endianness
for
all memory accesses (which could be changed at runtime),
We already do this, it's host native endian.
The simple fact that you used the word endian makes it
On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote:
It's not wrong when the hardware actually does a byteswap at
some level in the memory hierarchy. You can see this for instance
on ARMv7M systems, where
On Sat, 2013-07-13 at 00:10 +0100, Peter Maydell wrote:
The block marked byteswap here does byte invariant bigendian,
so byte accesses are unchanged, 16 bit accesses have the two words
of data flipped, and 32 bit accesses have the four bytes flipped;
this happens as the data passes through;
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote:
So IIUC before cpu_inw and inl were doing portio accesses in host
native endianness. Now with this change they do little endian
accesses. All sensible callers of cpu_inX assume that data is passed
in native endianness though and already
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote:
Semantically having your PCI host bridge do the endianness conversion
is the correct way of handling it, as that's where the conversion
happens. If it makes life easier to do it in the isa bridging code,
that's fine for me too though.
Am 12.07.2013 um 00:32 schrieb Benjamin Herrenschmidt
b...@kernel.crashing.org:
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote:
Semantically having your PCI host bridge do the endianness conversion
is the correct way of handling it, as that's where the conversion
happens. If it
17 matches
Mail list logo
