From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7wjQ-0003yd-Vw for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:40:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7wjJ-0000Qs-EA for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:40:48 -0500 Received: from mail-pb0-f43.google.com ([209.85.160.43]:41569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7wjJ-0008U7-8B for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:40:41 -0500 Received: by mail-pb0-f43.google.com with SMTP id md12so6584083pbc.2 for ; Mon, 27 Jan 2014 16:40:18 -0800 (PST) Date: Mon, 27 Jan 2014 16:40:15 -0800 From: Christoffer Dall Message-ID: <20140128004015.GA9687@cbox> References: <20140123204552.GA2977@lvm> <20140124021425.GA2961@lvm> <1390869161.3872.42.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1390869161.3872.42.camel@pasglop> Subject: Re: [Qemu-devel] [Qemu-ppc] KVM and variable-endianness guest CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Peter Maydell , Thomas Falcon , kvm-devel , Victor Kamensky , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" On Tue, Jan 28, 2014 at 11:32:41AM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2014-01-23 at 20:11 -0800, Victor Kamensky wrote: > > > I would take 50 byteswaps with a clear ABI any day over an obscure > > > standard that can avoid a single hardware-on-register instruction. > > This > > > is about designing a clean software interface, not about building an > > > optimized integrated stack. > > > > > > Unfortunately, this is going nowhere, so I think we need to stop > > this > > > thread. As you can see I have sent a patch as a clarification to > > the > > > ABI, if it's merged we can move on with more important tasks. > > > > OK, that is fine. I still believe is not the best choice, > > but I agree that we need to move on. I will respin my > > V7 KVM BE patches according to this new semantics, I will > > integrate comments that you (thanks!) and others gave me > > over mailing list and post my series again when it is ready. > > Right, the whole "host endian" is a horrible choice from every way you > look at it, but I'm afraid it's unfixable since it's already ABI :-( > Why is it a horrible choice? I don't think it's actually ABI at this point, it's undefined. The only thing fixed is PPC BE host and ARM LE host, and in both cases we currently perform a byteswap in KVM if the guest is a different endianness. Honestly I don't care which way it's defined, as long as it's defined somehow, and I have not yet seen anyone formulate how the ABI specification should be worded, so people clearly understand what's going on. If you take a look at the v2 patch "KVM: Specify byte order for KVM_EXIT_MMIO", that's where it ended up. If you can formulate something with your experience in endianness that makes this clear, it would be extremely helpful. -Christoffer