From: David Gibson <david@gibson.dropbear.id.au>
To: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
QEMU Developers <qemu-devel@nongnu.org>,
Alex Williamson <alex.williamson@redhat.com>,
zhong@linux.vnet.ibm.com, Paul Mackerras <paulus@samba.org>
Subject: Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive
Date: Fri, 24 Feb 2017 14:28:29 +1100 [thread overview]
Message-ID: <20170224032829.GP17615@umbus.fritz.box> (raw)
In-Reply-To: <df4e14ad-acd9-151e-f4a1-9cab24063b83@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]
On Fri, Feb 24, 2017 at 01:14:09AM +0800, Yongji Xie wrote:
> on 2017/2/24 0:15, Paolo Bonzini wrote:
>
> >
> > On 23/02/2017 17:08, Peter Maydell wrote:
> > > On 23 February 2017 at 15:58, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > > > However, DEVICE_NATIVE_ENDIAN would have to be paired with tswap, which
> > > > the current code does not do, hence the bug. To have no swap at all,
> > > > you'd need DEVICE_HOST_ENDIAN.
> > > Yes, I agree that the current ramdevice code has this bug (and
> > > that we can fix it by any of the various options).
> > Good. :)
> >
> > > > > AIUI what we want for this VFIO case is "when the guest does
> > > > > a 32-bit write of 0x12345678 then the bytes are 0x12 0x34 0x56 0x78
> > > > > regardless of whether TARGET_BIG_ENDIAN or not".
> > > > No, I don't think so. This is not specific to VFIO. You can do it with
> > > > any device, albeit VFIO is currently the only one using ramd regions.
> > > The commit message in the patch that started this thread off
> > > says specifically that "VFIO PCI device is little endian".
> > > Is that wrong?
> > Yes, I think it's a red herring. Hence my initial confusion, when I
> > asked "would Yongji's patch just work if it used DEVICE_BIG_ENDIAN and
> > beNN_to_cpu/cpu_to_beNN".
> >
>
> Thank you for the great discussion. I have a better understanding of the
> endianness now.:-)
>
> And for the commit message, I was wrong to assume the same endianness
> as vfio. That's my fault. This bug should happen when target and host
> endianness are different regardless of the device endianness.
>
> To fix it, introducing DEVICE_HOST_ENDIAN for the ram device seems to be
> more reasonable than other ways. I think I'll update the patch with this
> way.
I think this is basically the right approach, with the only caveat
being whether we want to call it "host endian" or something else.
> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
> index bd15853..eef74df 100644
> --- a/include/exec/cpu-common.h
> +++ b/include/exec/cpu-common.h
> @@ -36,6 +36,12 @@ enum device_endian {
> DEVICE_LITTLE_ENDIAN,
> };
>
> +#if defined(HOST_WORDS_BIGENDIAN)
> +#define DEVICE_HOST_ENDIAN DEVICE_BIG_ENDIAN
> +#else
> +#define DEVICE_HOST_ENDIAN DEVICE_LITTLE_ENDIAN
> +#endif
> +
> /* address in the RAM (different from a physical address) */
> #if defined(CONFIG_XEN_BACKEND)
> typedef uint64_t ram_addr_t;
> diff --git a/memory.c b/memory.c
> index ed8b5aa..17cfada 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -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_HOST_ENDIAN,
> .valid = {
> .min_access_size = 1,
> .max_access_size = 8,
>
> Thanks,
> Yongji
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-02-24 3:29 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
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 [this message]
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=20170224032829.GP17615@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--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).