From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5KNi-00089J-ON for qemu-devel@nongnu.org; Mon, 20 Jan 2014 14:19:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5KNX-0000QR-Fw for qemu-devel@nongnu.org; Mon, 20 Jan 2014 14:19:34 -0500 Received: from mail-pb0-f52.google.com ([209.85.160.52]:62417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5KNX-0000Q0-AJ for qemu-devel@nongnu.org; Mon, 20 Jan 2014 14:19:23 -0500 Received: by mail-pb0-f52.google.com with SMTP id jt11so5324218pbb.11 for ; Mon, 20 Jan 2014 11:19:21 -0800 (PST) Date: Mon, 20 Jan 2014 11:19:19 -0800 From: Christoffer Dall Message-ID: <20140120191919.GH13432@cbox> References: <03D15FE3-2A12-4D60-8D20-07D05F3740F6@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03D15FE3-2A12-4D60-8D20-07D05F3740F6@suse.de> Subject: Re: [Qemu-devel] KVM and variable-endianness guest CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Thomas Falcon , kvm-devel , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" On Mon, Jan 20, 2014 at 03:22:11PM +0100, Alexander Graf wrote: > > On 17.01.2014, at 19:52, Peter Maydell wrote: > > > On 17 January 2014 17:53, Peter Maydell wrote: > >> Specifically, the KVM API says "here's a uint8_t[] byte > >> array and a length", and the current QEMU code treats that > >> as "this is a byte array written as if the guest CPU > >> (a) were in TARGET_WORDS_BIGENDIAN order and (b) wrote its > >> I/O access to this buffer rather than to the device". > >> > >> The KVM API docs don't actually specify the endianness > >> semantics of the byte array, but I think that that really > >> needs to be nailed down. I can think of a couple of options: > >> * always LE > >> * always BE > >> [these first two are non-starters because they would > >> break either x86 or PPC existing code] > >> * always the endianness the guest is at the time > >> * always some arbitrary endianness based purely on the > >> endianness the KVM implementation used historically > >> * always the endianness of the host QEMU binary > >> * something else? > >> > >> Any preferences? Current QEMU code basically assumes > >> "always the endianness of TARGET_WORDS_BIGENDIAN", > >> which is pretty random. > > > > Having thought a little more about this, my opinion is: > > > > * we should specify that the byte order of the mmio.data > > array is host kernel endianness (ie same endianness > > as the QEMU process itself) [this is what it actually > > is, I think, for all the cases that work today] > > * we should fix the code path in QEMU for handling > > mmio.data which currently has the implicit assumption > > that when using KVM TARGET_WORDS_BIGENDIAN is the same > > as the QEMU host process endianness (because it's using > > load/store functions which swap if TARGET_WORDS_BIGENDIAN > > is different from HOST_WORDS_BIGENDIAN) > > Yes, I fully agree :). > Great, I'll prepare a patch for the KVM API documentation. -Christoffer