From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4NS8-0005vC-Ck for qemu-devel@nongnu.org; Fri, 17 Jan 2014 23:24:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4NS2-0005wZ-Ia for qemu-devel@nongnu.org; Fri, 17 Jan 2014 23:24:12 -0500 Received: from mail-pd0-f171.google.com ([209.85.192.171]:43559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4NS2-0005wF-Co for qemu-devel@nongnu.org; Fri, 17 Jan 2014 23:24:06 -0500 Received: by mail-pd0-f171.google.com with SMTP id g10so4018604pdj.16 for ; Fri, 17 Jan 2014 20:24:05 -0800 (PST) Date: Fri, 17 Jan 2014 20:24:01 -0800 From: Christoffer Dall Message-ID: <20140118042401.GB4021@cbox> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] KVM and variable-endianness guest CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Thomas Falcon , kvm-devel , Alexander Graf , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" On Fri, Jan 17, 2014 at 06:52:57PM +0000, 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] I completely agree, given that it's too late to be set on always LE/BE, I think the natural choice is something that allows a user to cast the byte array to an appropriate pointer type and dereference it. And I think we need to amend the KVM API docs to specify this. -- Christoffer