qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	Yongji Xie <xyjxie@linux.vnet.ibm.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	zhong@linux.vnet.ibm.com,
	David Gibson <david@gibson.dropbear.id.au>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive
Date: Thu, 23 Feb 2017 09:08:39 -0700	[thread overview]
Message-ID: <20170223090839.148b0f3f@t450s.home> (raw)
In-Reply-To: <643953df-0954-210c-6fc5-ff229fbcac84@redhat.com>

On Thu, 23 Feb 2017 16:47:23 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 23/02/2017 16:39, Alex Williamson wrote:
> > On Thu, 23 Feb 2017 16:21:47 +0100
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> >   
> >> On 23/02/2017 15:35, Peter Maydell wrote:  
> >>> On 23 February 2017 at 12:53, Paolo Bonzini <pbonzini@redhat.com> wrote:    
> >>>>
> >>>>
> >>>> On 23/02/2017 13:26, Peter Maydell wrote:    
> >>>>> On 23 February 2017 at 11:43, Paolo Bonzini <pbonzini@redhat.com> wrote:    
> >>>>>> On 23/02/2017 12:34, Peter Maydell wrote:    
> >>>>>>> We should probably update the doc comment to note that the
> >>>>>>> pointer is to host-endianness memory (and that this is not
> >>>>>>> like normal RAM which is target-endian)...    
> >>>>>>
> >>>>>> I wouldn't call it host-endianness memory, and I disagree that normal
> >>>>>> RAM is target-endian---in both cases it's just a bunch of bytes.
> >>>>>>
> >>>>>> However, the access done by the MemoryRegionOps callbacks needs to match
> >>>>>> the endianness declared by the MemoryRegionOps themselves.    
> >>>>>
> >>>>> Well, if the guest stores a bunch of integers to the memory, which
> >>>>> way round do you see them when you look at the bunch of bytes?    
> >>>>
> >>>> You see them in whatever endianness the guest used.    
> >>>
> >>> I'm confused. I said "normal RAM and this ramdevice memory are
> >>> different", and you seem to be saying they're the same. I don't
> >>> think they are (in particular I think with a BE guest on an
> >>> LE host they'll look different).    
> >>
> >> No, they look entirely the same.  The only difference is that they go
> >> through MemoryRegionOps instead of memcpy.  
> > 
> > Is this true for vfio use case?  If we use memcpy we're talking directly
> > to the device with no endian conversions.  If we use read/write then
> > there is an endian conversion in the host kernel.  
> 
> But ramd MemoryRegionOps do not use file read/write, they use memory
> read/write, so they talk directly to the device.

Ah ha!  Ding! ;)  Sorry, I forgot that.

  reply	other threads:[~2017-02-23 16:08 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
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 [this message]
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=20170223090839.148b0f3f@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --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).