From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC1qo-0004jc-Ll for qemu-devel@nongnu.org; Mon, 06 Jul 2015 04:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZC1ql-0004T0-BL for qemu-devel@nongnu.org; Mon, 06 Jul 2015 04:34:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC1ql-0004Su-4l for qemu-devel@nongnu.org; Mon, 06 Jul 2015 04:34:03 -0400 Date: Mon, 6 Jul 2015 11:33:59 +0300 From: "Michael S. Tsirkin" Message-ID: <20150706105048-mutt-send-email-mst@redhat.com> References: <1435842022-13980-1-git-send-email-mst@redhat.com> <5595876E.2040803@redhat.com> <20150702205556-mutt-send-email-mst@redhat.com> <55958AE2.1020600@redhat.com> <20150704230256-mutt-send-email-mst@redhat.com> <559A3246.7020103@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <559A3246.7020103@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: peter.maydell@linaro.org, hpoussin@reactos.org, qemu-devel@nongnu.org On Mon, Jul 06, 2015 at 09:46:14AM +0200, Paolo Bonzini wrote: >=20 >=20 > On 04/07/2015 23:19, Michael S. Tsirkin wrote: > > The fact that address_space_write/_read actually does a byteswap if > > host!=3Dtarget endian should probably be documented. >=20 > FWIW, it's not if host !=3D target endian. It's if memory region > endianness !=3D target endianness. See memory_region_wrong_endianness. Right. What I meant is that if device !=3D host then we want a byteswap anyway. E.g. if device says it's BE and system is LE, then it does want to get byte 0 as MSB in the uint32 it gets. IOW we want byteswap if host !=3D MR. Instead we get a byteswap if target !=3D MR. This is the same unless host !=3D target. > > Or maybe it should be changed: it seems likely that non-target-specif= ic devices > > that use it do this incorrectly ATM. In particular, dma_memory_rw_rel= axed calls > > address_space_rw and since DMA originates with devices I think there'= s very > > little chance that these actually want a different behaviour dependin= g on the > > target endian-ness. > >=20 > > Most likely, these only work correctly because DMA outside RAM > > is highly unusual. >=20 > They work correctly because of that, and because most devices *and* > targets are little endian so you have no swap. On ppc64, which has > TARGET_WORDS_BIGENDIAN, it probably wouldn't work correctly. >=20 > Paolo Also, by luck, some values work the same whatever the endian-ness. E.g. dma_memory_set fills the buffer with a given pattern, so nothing changes if you byte-swap it. Here's an example that's wrong: dp8393x. Typically it's accessing memory for DMA, so there's no byteswap. Works fine. But should device attempt to access another device memory, it would break because MIPS target is BE. Cc Herv=E9 for confirmation. I conclude that virtio is not so special in needing a variant of address_space_rw that assumes host endian format for the data. --=20 MST