From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [PATCH] KVM: PPC: Book3S HV: return htab entries in big endian Date: Fri, 3 Oct 2014 22:05:07 +1000 Message-ID: <20141003120507.GA10764@iris.ozlabs.ibm.com> References: <1412269080-18510-1-git-send-email-clg@fr.ibm.com> <542D8620.2060503@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: =?iso-8859-1?Q?C=E9dric?= Le Goater , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, Alexey Kardashevskiy To: Alexander Graf Return-path: Content-Disposition: inline In-Reply-To: <542D8620.2060503@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Oct 02, 2014 at 07:06:40PM +0200, Alexander Graf wrote: > > I think we're best off to keep the user space API native endian. So > really we should only ever have to convert from big to native endian on > read and native to big on write. > > With that QEMU should do the "right thing" already, no? I believe that when migrating a guest, QEMU just passes the byte stream it gets from the htab fd along to the destination QEMU with little or no interpretation, and the destination QEMU writes the byte stream to the htab fd for the receiving VM. Alexey would be able to say for sure. If that's the case, then perhaps it's best to define that byte stream to contain values of one specific endianness, and for compatibility that would be big endian. I assume we would want to be able to migrate a guest from a BE host to an LE host or vice versa. If not then the question is moot. Paul.