From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5FtE-0001Mg-6W for qemu-devel@nongnu.org; Mon, 20 Jan 2014 09:31:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Ft9-0001zr-8k for qemu-devel@nongnu.org; Mon, 20 Jan 2014 09:31:48 -0500 Received: from mail-lb0-f178.google.com ([209.85.217.178]:44072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ft9-0001zd-2h for qemu-devel@nongnu.org; Mon, 20 Jan 2014 09:31:43 -0500 Received: by mail-lb0-f178.google.com with SMTP id u14so5019902lbd.9 for ; Mon, 20 Jan 2014 06:31:42 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <176E0926-A4AF-4D85-9C07-3F32B2AE01B2@suse.de> References: <20140118042401.GB4021@cbox> <176E0926-A4AF-4D85-9C07-3F32B2AE01B2@suse.de> From: Peter Maydell Date: Mon, 20 Jan 2014 14:31:21 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Thomas Falcon , kvm-devel , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall On 20 January 2014 14:20, Alexander Graf wrote: > I think I see the problem now. You're thinking about LE hosts, not LE guests. > > I think the only really sensible options would be to > > a) Always use a statically define target endianness (big for ppc) > b) Always use host endianness > Currently QEMU apparently implements a), but that can > easily be changed. Today we don't have kvm support for > ppc64le hosts yet. Yes; I would ideally like us be able to get rid of that statically defined target endianness eventually, so if we have the leeway to define the kernel<->userspace ABI in a way that doesn't care about the current guest CPU endianness (ie we haven't actually yet claimed support for reverse-endianness guests in a way that locks us into an unhelpful definition of the ABI) we should take it while we still can. Then the current QEMU restrictions boil down to "you can only use QEMU for KVM on a host kernel with the same endianness as QEMU's legacy TARGET_WORDS_BIGENDIAN setting for that CPU" (but such a QEMU can deal with guests whatever they do with the endianness control bits). > I personally prefer b). It's the natural thing to do for > a host interface to be in host endianness and it's exactly > what we expose for LE-on-BE systems with ppc already. Yes. Strictly speaking by "host endianness" here I guess we mean "the endianness of the kernel-to-userspace ABI", since it is at least in theory possible to have an LE kernel which runs BE userspace processes. thanks -- PMM