From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7cuM-0006GQ-Bs for qemu-devel@nongnu.org; Thu, 08 Aug 2013 22:58:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7cuL-0000Fq-7y for qemu-devel@nongnu.org; Thu, 08 Aug 2013 22:58:30 -0400 Received: from ozlabs.org ([2402:b800:7003:1:1::1]:60310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7cuK-0000Cw-Q3 for qemu-devel@nongnu.org; Thu, 08 Aug 2013 22:58:29 -0400 From: Rusty Russell In-Reply-To: <87pptof9nn.fsf@codemonkey.ws> References: <1375938949-22622-1-git-send-email-rusty@rustcorp.com.au> <1375938949-22622-2-git-send-email-rusty@rustcorp.com.au> <87li4cgvh1.fsf@codemonkey.ws> <5203AB19.9070505@suse.de> <87r4e4p4wj.fsf@codemonkey.ws> <20130808154507.GX14664@redhat.com> <87pptof9nn.fsf@codemonkey.ws> Date: Fri, 09 Aug 2013 12:28:10 +0930 Message-ID: <87vc3fo9j1.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , "Daniel P. Berrange" Cc: Peter Maydell , Andreas =?utf-8?Q?F=C3=A4rber?= , anton@samba.org, qemu-devel@nongnu.org Anthony Liguori writes: > "Daniel P. Berrange" writes: > >> On Thu, Aug 08, 2013 at 10:40:28AM -0500, Anthony Liguori wrote: >>> Andreas F=C3=A4rber writes: >>> >> We have a mechanism to do weak functions via stubs/. I think it wou= ld >>> >> be better to do cpu_get_byteswap() as a stub function and then overl= oad >>> >> it in the ppc64 code. >>> > >>> > If this as your name indicates is a per-CPU function then it should go >>> > into CPUClass. Interesting question is, what is virtio supposed to do= if >>> > we have two ppc CPUs, one is Big Endian, the other is Little Endian. >>>=20 >>> PPC64 is big endian. AFAIK, there is no such thing as a little endian >>> PPC64 processor. >> >> Unless I'm misunderstanding, this thread seems to suggest otherwise: >> >> "[Qemu-devel] [PATCH 0/5] 64bit PowerPC little endian support" >> >> https://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00813.html > > Yeah, it's confusing. It feels like little endian to most software but > the distinction in hardware (and therefore QEMU) is important. > > It's the same processor. It still starts executing big endian > instructions. A magic register value is tweaked and loads/stores are > swapped. CPU data structures are still read as big endian though. It's > really just load/stores that are affected. > > The distinction is important in QEMU. ppc64 is still > TARGET_WORDS_BIGENDIAN. We still want most stl_phys to treat integers > as big endian. There's just this extra concept that CPU loads/stores > are sometimes byte swapped. That affects virtio but not a lot else. You've redefined endian here; please don't do that. Endian is the order in memory which a CPU does loads and stores. From any reasonable definition, PPC is bi-endian. It's actually a weird thing for the qemu core to know at all: almost everything which cares is in target-specific code. The exceptions are gdb stubs and virtio, both of which are "native endian" (and that weird code in exec.c: what is notdirty_mem_write?). Your argument that we shouldn't fix stl_* might be justifiable (ie. just hack virtio and gdb as one-offs), but it's neither clear nor "least surprise". Chers, Rusty.