From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6hrU-0006PQ-K5 for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:36:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6hrO-0001w4-Ku for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:36:00 -0500 Received: from mail-la0-f51.google.com ([209.85.215.51]:49294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6hrM-0001vm-1t for qemu-devel@nongnu.org; Fri, 24 Jan 2014 09:35:54 -0500 Received: by mail-la0-f51.google.com with SMTP id c6so2651180lan.10 for ; Fri, 24 Jan 2014 06:35:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <52E2790C.20304@redhat.com> References: <1390515366-32236-1-git-send-email-wei.liu2@citrix.com> <52E2790C.20304@redhat.com> From: Peter Maydell Date: Fri, 24 Jan 2014 14:35:30 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Paolo Bonzini Cc: Anthony PERARD , "xen-devel@lists.xen.org" , Wei Liu , QEMU Developers , Stefano Stabellini On 24 January 2014 14:30, Paolo Bonzini wrote: > Il 23/01/2014 23:30, Peter Maydell ha scritto: >> I'm afraid I still think this is a terrible idea. "Xen" isn't a CPU, and >> "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? > > > (1) decide that the Xen ring buffers are little-endian even on big-endian > CPUs > > (2) communicate the endianness of the Xen ring buffers via Xenstore, just > like we do for sizeof(long), and let the guest use either endianness on any > architecture. You still have to make a choice about what you think TARGET_WORDS_BIGENDIAN should be, and it's still going to be wrong half the time and horribly confusing. I just think this is completely the wrong solution to the problem. If Xen really wants a totally standalone binary of the smallest possible size with just paravirtualized hardware and minimal to no dependency on guest CPU architecture then they should write one, along the lines of kvmtool :-) thanks -- PMM