From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0X33-0006eX-SF for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:50:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0X2v-00080y-FR for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:50:25 -0500 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:63221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0X2v-00080q-8D for qemu-devel@nongnu.org; Tue, 07 Jan 2014 08:50:17 -0500 Received: by mail-ee0-f43.google.com with SMTP id c13so87199eek.2 for ; Tue, 07 Jan 2014 05:50:16 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52CC0614.5050402@redhat.com> Date: Tue, 07 Jan 2014 14:50:12 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20140106125410.GD3119@zion.uk.xensource.com> <20140106151154.GA10654@zion.uk.xensource.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Project idea: make QEMU more flexible List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Peter Maydell , Peter Crosthwaite , Wei Liu , "qemu-devel@nongnu.org Developers" , "xen-devel@lists.xen.org" Il 07/01/2014 14:26, Stefano Stabellini ha scritto: > > The identifiers poisoned by include/qemu/poison.h are > > an initial but not complete list. Host and target > > endianness is a particularly obvious one, as is the > > size of a target long. You may not use these things > > in your Xen devices, but "qemu-system-null" implies > > more than "weird special purpose thing which only > > has Xen devices in it". > > I see your point. > Could we allow target endinness and long size being selected at > configure time for target-null? > The default could be the same as the host, or could even be simply > statically determined, maybe little endian, 4 bytes. For Xen both long sizes are already supported by the block backend. Are there still guests that use BLKIF_PROTOCOL_NATIVE? If not, long size might not matter at all. And if in the future Xen were to grow support for a big-endian target, you could either enforce little-endian for the ring buffers, or negotiate it in xenstore like you do for sizeof(long). So let's call things by their name and add qemu-system-xenpv that covers both x86 and ARM and anything else in the future. Phasing out the i386/x86_64 xenpv machine type makes total sense if the exact same code can support ARM PV domains too. This machine would only be compiled if you had support for Xen. My current patches have: supported_target() { test "$tcg" = "yes" && return 0 supported_kvm_target && return 0 supported_xen_target && return 0 return 1 } but adding a more refined test for supported-on-TCG would be easy. Paolo