From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7hhq-0001eK-DK for qemu-devel@nongnu.org; Fri, 09 Aug 2013 04:05:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7hhl-0003F9-I5 for qemu-devel@nongnu.org; Fri, 09 Aug 2013 04:05:54 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:33111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7hhl-0003Eu-0y for qemu-devel@nongnu.org; Fri, 09 Aug 2013 04:05:49 -0400 Received: by mail-la0-f46.google.com with SMTP id eh20so2799337lab.5 for ; Fri, 09 Aug 2013 01:05:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87vc3fo9j1.fsf@rustcorp.com.au> 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> <87vc3fo9j1.fsf@rustcorp.com.au> From: Peter Maydell Date: Fri, 9 Aug 2013 09:05:27 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Rusty Russell Cc: anton@samba.org, =?UTF-8?Q?Andreas_F=C3=A4rber?= , Anthony Liguori , qemu-devel@nongnu.org On 9 August 2013 03:58, Rusty Russell wrote: > Anthony Liguori writes: >> 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. Agreed (subject to the complicating factor that it's possible for a CPU to have the order to be different for data, instruction and TLB walk loads, so it's not a single setting for a CPU). > From any reasonable definition, PPC is bi-endian. > > It's actually a weird thing for the qemu core to know at all: It's a TCG performance optimisation and/or simplification hack, basically -- by hardcoding the endianness we think the core is at compile time we can either always-byteswap or never-byteswap in the fast paths. > 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?). The code for actually doing TCG CPU loads and stores cares too. notdirty_mem_write is (I think) part of how we handle self-modifying code: if you write to a page in memory that we have translated some code from, then we need to intercept that write so that we can throw away the translated code. notdirty_mem_write() is the function that does that interception, throws away the code, figures out if we still need to intercept next time around, and actually does the access the guest asked for. (It might also be used for spotting when the guest touches memory during migration and thus that page needs to be retransmitted -- I haven't checked.) -- PMM