[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] memory: Introduce DEVICE_HOST_ENDIAN for ram
Re: [Qemu-devel] [PATCH v2] memory: Introduce DEVICE_HOST_ENDIAN for ram device
Tue, 28 Feb 2017 18:12:56 +0800
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
on 2017/2/28 8:41, David Gibson wrote:
On Mon, Feb 27, 2017 at 12:52:44PM +0800, Yongji Xie wrote:
At the moment ram device's memory regions are DEVICE_NATIVE_ENDIAN. It's
incorrect. This memory region is backed by a MMIO area in host, so the
uint64_t data that MemoryRegionOps read from/write to this area should be
host-endian rather than target-endian. Hence, current code does not work
when target and host endianness are different which is the most common case
on PPC64. To fix it, this introduces DEVICE_HOST_ENDIAN for the ram device.
This has been tested on PPC64 BE/LE host/guest in all possible combinations
Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Yongji Xie <address@hidden>
Reviewed-by: David Gibson <address@hidden>
The effect of the patch is certainly correct. I remain a little
concerned that the name "host endian" might cause more confusion than
it resolves, but a better term isn't immediately obvious to me.
If the memory region's endianness indicates the endianness of multi-byte
MemoryRegionOps read from/write to this memory region, should "host endian"
For a mmio store, QEMU just get a bunch of bytes in the memory at the
Then we use ldX_p to load a target-endian multi-byte value from the
adjust_endianness() change the endianness of the multi-byte value from
to memory region's endianness.
For the mmap MMIO area, we should use host-endian multi-byte value to
*(uint32_t *)(mr->ram_block->host + addr) = (uint32_t)data;
Here it is the same as stl_he_p().
The "host-endian" means we load a bunch of bytes as a host-endian value,
and write the
value to the mmap MMIO area. That's my understanding. Not sure if it's