qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).