From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Xqv-00070p-0N for qemu-devel@nongnu.org; Tue, 07 Jan 2014 09:42:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0Xqc-0006vE-0j for qemu-devel@nongnu.org; Tue, 07 Jan 2014 09:41:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Xqb-0006u5-NR for qemu-devel@nongnu.org; Tue, 07 Jan 2014 09:41:37 -0500 Message-ID: <52CC11DA.4050508@redhat.com> Date: Tue, 07 Jan 2014 15:40:26 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20140106125410.GD3119@zion.uk.xensource.com> <20140106151154.GA10654@zion.uk.xensource.com> <52CC0614.5050402@redhat.com> <20140107143857.GI10654@zion.uk.xensource.com> In-Reply-To: <20140107143857.GI10654@zion.uk.xensource.com> 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: Wei Liu Cc: Peter Maydell , Peter Crosthwaite , "xen-devel@lists.xen.org" , "qemu-devel@nongnu.org Developers" , Stefano Stabellini Il 07/01/2014 15:38, Wei Liu ha scritto: > On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote: >> 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 > > I think this makes sense. But does it deserve to be in default-configs/? Sure. You could build a qemu-system-xenpv variant that doesn't have the framebuffer, for example. > It will become default-configs/xenpv-softmmu.mak and target-xenpv shall be > created. Yes, exactly. > I think implementing qemu-system-xenpv will be easier after your TCG > series goes in. In that case I don't need to worry about TCG stubs > anymore. Right. Paolo