From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgvcA-00078d-TF for qemu-devel@nongnu.org; Thu, 23 Feb 2017 10:47:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgvc7-0002EG-Q2 for qemu-devel@nongnu.org; Thu, 23 Feb 2017 10:47:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42350) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cgvc7-0002Dw-HR for qemu-devel@nongnu.org; Thu, 23 Feb 2017 10:47:27 -0500 References: <1487659615-15820-1-git-send-email-xyjxie@linux.vnet.ibm.com> <5edff645-12e8-d3e0-1849-302b6986c232@ozlabs.ru> <5a0773de-6bc7-474a-82ab-2edd37ce8a93@redhat.com> <92580ca9-47fe-a943-7720-d3cb1fc6d2eb@redhat.com> <3d5e7b5e-4501-86b7-093d-47fb09af585e@redhat.com> <41630a89-e645-7d7e-b7c2-356fd6dcadee@redhat.com> <2565ef99-9c16-e836-08c6-0915f5d4b0f8@redhat.com> <20170223083908.657bf257@t450s.home> From: Paolo Bonzini Message-ID: <643953df-0954-210c-6fc5-ff229fbcac84@redhat.com> Date: Thu, 23 Feb 2017 16:47:23 +0100 MIME-Version: 1.0 In-Reply-To: <20170223083908.657bf257@t450s.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Peter Maydell , Alexey Kardashevskiy , Yongji Xie , QEMU Developers , zhong@linux.vnet.ibm.com, David Gibson , Paul Mackerras On 23/02/2017 16:39, Alex Williamson wrote: > On Thu, 23 Feb 2017 16:21:47 +0100 > Paolo Bonzini wrote: > >> On 23/02/2017 15:35, Peter Maydell wrote: >>> On 23 February 2017 at 12:53, Paolo Bonzini wrote: >>>> >>>> >>>> On 23/02/2017 13:26, Peter Maydell wrote: >>>>> On 23 February 2017 at 11:43, Paolo Bonzini 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. Paolo