qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Date: Sat, 13 Jul 2013 08:39:07 +1000

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 0x80000092, the 
> program needs to issue 0x80000095 instead, to compensate (unmunge) for 
> the effect of PowerPC address modification."
> 
> Those will be required for QEMU to be able to run BeOS, AIX, or Windows 
> NT or PowerPC PReP.

Funnily enough we've dropped support for Linux on PReP a long time
ago :-)

> In the light of this, I think there should only be one endianness for 
> all memory accesses (which could be changed at runtime), and all 
> bridges/devices should ask for "same endianness as parent" or "reverse 
> endianness as parent", but not for big, little, or native endianness.

Right. I would in fact avoid the term "endianness" that tends to confuse
people and basically stick to this:

 - For a given access, know (attribute) which byte is first in ascending
address order

 - For a given target *register* (and again, this ONLY applies to registers
and in fact, some devices might change their register "endianness" and also
have several banks with a different one), which byte is first in ascending
address order.

This is at that point that a conversion might need to occur, and only at that
point if there is a mismatch.

Ben.





reply via email to

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