On 01/28/2014 01:27 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-01-22 at 17:29 +0000, Peter Maydell wrote:
Basically if it would be on real bus, get byte value
that corresponds to phys_addr + 0 address place
it into data[0], get byte value that corresponds to
phys_addr + 1 address place it into data[1], etc.
This just isn't how real buses work.
Actually it can be :-)
There is no
"address + 1, address + 2". There is a single address
for the memory transaction and a set of data on
data lines and some separate size information.
How the device at the far end of the bus chooses
to respond to 32 bit accesses to address X versus
8 bit accesses to addresses X through X+3 is entirely
its own business and unrelated to the CPU.
However the bus has a definition of what byte lane is the lowest in
address order. Byte order invariance is an important function of
all busses.
I think that trying to treat it any differently than an address
ordered series of bytes is going to turn into a complete and
inextricable mess.
I agree.
The two options are:
(address, byte array, length)
and
(address, value, word size, endianness)
the first is the KVM ABI, the second is how MemoryRegions work. Both are
valid, but the first is more general (supports the 3-byte accesses
sometimes generated on x86).
(It would
be perfectly possible to have a device which when
you read from address X as 32 bits returned 0x12345678,
when you read from address X as 16 bits returned
0x9abc, returned 0x42 for an 8 bit read from X+1,
and so on. Having byte reads from X..X+3 return
values corresponding to parts of the 32 bit access
is purely a convention.)
Right, it's possible. It's also stupid and not how most modern devices
and busses work. Besides there is no reason why that can't be
implemented with Victor proposal anyway.
Right.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
