From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
Yongji Xie <xyjxie@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, aik@ozlabs.ru, zhong@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive
Date: Tue, 21 Feb 2017 17:34:50 +0100 [thread overview]
Message-ID: <27972408-a43b-60f9-86ad-e4e47f4f8f14@redhat.com> (raw)
In-Reply-To: <20170221092137.5b6cecbb@t450s.home>
On 21/02/2017 17:21, Alex Williamson wrote:
> On Tue, 21 Feb 2017 14:46:55 +0800
> Yongji Xie <xyjxie@linux.vnet.ibm.com> wrote:
>
>> At the moment ram device's memory regions are NATIVE_ENDIAN. This does
>> not work on PPC64 because VFIO PCI device is little endian but PPC64
>> always defines static macro TARGET_WORDS_BIGENDIAN.
>>
>> This fixes endianness for ram device the same way as it is done
>> for VFIO region in commit 6758008e2c4e79fb6bd04fe8e7a41665fa583965.
>
> The referenced commit was to vfio code where the endianness is fixed,
> here you're modifying shared generic code to assume the same
> endianness as vfio. That seems wrong.
Is the goal to have the same endianness as VFIO? Or is it just a trick
to ensure the number of swaps is always 0 or 2, so that they cancel away?
In other words, would Yongji's patch just work if it used
DEVICE_BIG_ENDIAN and beNN_to_cpu/cpu_to_beNN? If so, then I think the
patch is okay.
Paolo
>
> Alex
>
>> Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
>> ---
>> memory.c | 14 +++++++-------
>> 1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/memory.c b/memory.c
>> index 6c58373..1ccb99f 100644
>> --- a/memory.c
>> +++ b/memory.c
>> @@ -1139,13 +1139,13 @@ static uint64_t memory_region_ram_device_read(void *opaque,
>> data = *(uint8_t *)(mr->ram_block->host + addr);
>> break;
>> case 2:
>> - data = *(uint16_t *)(mr->ram_block->host + addr);
>> + data = le16_to_cpu(*(uint16_t *)(mr->ram_block->host + addr));
>> break;
>> case 4:
>> - data = *(uint32_t *)(mr->ram_block->host + addr);
>> + data = le32_to_cpu(*(uint32_t *)(mr->ram_block->host + addr));
>> break;
>> case 8:
>> - data = *(uint64_t *)(mr->ram_block->host + addr);
>> + data = le64_to_cpu(*(uint64_t *)(mr->ram_block->host + addr));
>> break;
>> }
>>
>> @@ -1166,13 +1166,13 @@ static void memory_region_ram_device_write(void *opaque, hwaddr addr,
>> *(uint8_t *)(mr->ram_block->host + addr) = (uint8_t)data;
>> break;
>> case 2:
>> - *(uint16_t *)(mr->ram_block->host + addr) = (uint16_t)data;
>> + *(uint16_t *)(mr->ram_block->host + addr) = cpu_to_le16((uint16_t)data);
>> break;
>> case 4:
>> - *(uint32_t *)(mr->ram_block->host + addr) = (uint32_t)data;
>> + *(uint32_t *)(mr->ram_block->host + addr) = cpu_to_le32((uint32_t)data);
>> break;
>> case 8:
>> - *(uint64_t *)(mr->ram_block->host + addr) = data;
>> + *(uint64_t *)(mr->ram_block->host + addr) = cpu_to_le64(data);
>> break;
>> }
>> }
>> @@ -1180,7 +1180,7 @@ static void memory_region_ram_device_write(void *opaque, hwaddr addr,
>> static const MemoryRegionOps ram_device_mem_ops = {
>> .read = memory_region_ram_device_read,
>> .write = memory_region_ram_device_write,
>> - .endianness = DEVICE_NATIVE_ENDIAN,
>> + .endianness = DEVICE_LITTLE_ENDIAN,
>> .valid = {
>> .min_access_size = 1,
>> .max_access_size = 8,
>
next prev parent reply other threads:[~2017-02-21 16:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 6:46 [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive Yongji Xie
2017-02-21 16:21 ` Alex Williamson
2017-02-21 16:34 ` Paolo Bonzini [this message]
2017-02-21 18:09 ` Peter Maydell
2017-02-21 18:44 ` Alex Williamson
2017-02-22 7:54 ` Yongji Xie
2017-02-22 10:53 ` Paolo Bonzini
2017-02-21 18:53 ` Paolo Bonzini
2017-02-21 19:40 ` Peter Maydell
2017-02-23 4:20 ` Alexey Kardashevskiy
2017-02-23 8:35 ` Paolo Bonzini
2017-02-23 10:02 ` Peter Maydell
2017-02-23 10:10 ` Paolo Bonzini
2017-02-23 10:23 ` Peter Maydell
2017-02-23 10:33 ` Paolo Bonzini
2017-02-23 11:34 ` Peter Maydell
2017-02-23 11:43 ` Paolo Bonzini
2017-02-23 12:26 ` Peter Maydell
2017-02-23 12:53 ` Paolo Bonzini
2017-02-23 14:35 ` Peter Maydell
2017-02-23 15:21 ` Paolo Bonzini
2017-02-23 15:29 ` Peter Maydell
2017-02-23 15:58 ` Paolo Bonzini
2017-02-23 16:08 ` Peter Maydell
2017-02-23 16:15 ` Paolo Bonzini
2017-02-23 17:14 ` Yongji Xie
2017-02-24 3:28 ` David Gibson
2017-02-23 23:36 ` Paul Mackerras
2017-02-23 15:39 ` Alex Williamson
2017-02-23 15:47 ` Paolo Bonzini
2017-02-23 16:08 ` Alex Williamson
2017-02-24 3:26 ` David Gibson
2017-02-23 11:04 ` Alexey Kardashevskiy
2017-02-27 2:25 ` Michael Roth
2017-02-27 3:25 ` Alexey Kardashevskiy
2017-02-27 4:28 ` Yongji Xie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27972408-a43b-60f9-86ad-e4e47f4f8f14@redhat.com \
--to=pbonzini@redhat.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xyjxie@linux.vnet.ibm.com \
--cc=zhong@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).