From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6huB-0003Ef-LM for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:38:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6hu5-0002fy-Pg for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:38:47 -0500 Received: from mail-ea0-f169.google.com ([209.85.215.169]:37139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6hu5-0002fo-GT for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:38:41 -0500 Received: by mail-ea0-f169.google.com with SMTP id l9so895673eaj.0 for ; Fri, 24 Jan 2014 06:38:05 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52E27AC9.8050506@redhat.com> Date: Fri, 24 Jan 2014 15:38:01 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1390515366-32236-1-git-send-email-wei.liu2@citrix.com> <20140124142337.GH24675@zion.uk.xensource.com> In-Reply-To: <20140124142337.GH24675@zion.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Liu , Peter Maydell Cc: Anthony PERARD , "xen-devel@lists.xen.org" , QEMU Developers , Stefano Stabellini Il 24/01/2014 15:23, Wei Liu ha scritto: > On Thu, Jan 23, 2014 at 10:30:16PM +0000, Peter Maydell wrote: >> On 23 January 2014 22:16, Wei Liu wrote: >>> As promised I hacked a prototype based on Paolo's disable TCG series. >>> However I coded some stubs for TCG anyway. So this series in principle >>> should work with / without Paolo's series. >> >> I'm afraid I still think this is a terrible idea. "Xen" isn't a CPU, and > > Thanks for being blunt. ;-) > >> "the binary is smaller" isn't IMHO sufficient justification for breaking >> QEMU's basic structure of "target-* define target CPUs and we have >> a lot of compile time constants which are specific to a CPU which >> get defined there". How would you support a bigendian Xen CPU, >> just to pick one example of where this falls down? >> > > I think about this deeper. From Xen's (and I speculate this applies to > other hardware assisted virtulization solution as well) PoV only the > native endianess is supported, does it make sense to have a > target-native thing? I think this is wrong, for a few reasons: (1) xenpv is not hardware assisted virtualization (2) supporting only native endianness leads to complications when systems are bi-endian, as is the case for PPC. For example, virtio 1.0 will always be little endian. (3) there's a precedent for supporting different guests between the guest and the host in blkback, you can do the same for endianness. Paolo