From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQzzq-00084a-PD for qemu-devel@nongnu.org; Thu, 07 Aug 2008 03:33:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQzzq-00084K-6e for qemu-devel@nongnu.org; Thu, 07 Aug 2008 03:33:18 -0400 Received: from [199.232.76.173] (port=39166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQzzq-00084H-0V for qemu-devel@nongnu.org; Thu, 07 Aug 2008 03:33:18 -0400 Received: from mx1.redhat.com ([66.187.233.31]:49115) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQzzp-0003zy-Lc for qemu-devel@nongnu.org; Thu, 07 Aug 2008 03:33:17 -0400 Message-ID: <489AA532.7040006@redhat.com> Date: Thu, 07 Aug 2008 09:33:06 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu References: <20080805150328.GT4478@implementation.uk.xensource.com> <20080805154140.GV4478@implementation.uk.xensource.com> <48997981.1030703@redhat.com> <20080806102338.GA4448@implementation.uk.xensource.com> <20080806125055.GG4448@implementation.uk.xensource.com> <4899AD19.8060606@redhat.com> <20080806140132.GL4448@implementation.uk.xensource.com> <4899B06F.2090101@redhat.com> <20080806142526.GN4448@implementation.uk.xensource.com> <20080806221047.GE4486@implementation> In-Reply-To: <20080806221047.GE4486@implementation> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samuel Thibault , Gerd Hoffmann , Markus Armbruster , Anthony Liguori , qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Ian Jackson Samuel Thibault wrote: > Samuel Thibault, le Wed 06 Aug 2008 15:25:26 +0100, a =E9crit : >> Pushing the cleaning changes to Xen first can be done and would entail >> much easier to tackle breakage, and the merge back from qemu would the= n >> be trivial, why not doing so? >=20 > You didn't answer that part. Really, my only concern is about having > things tested. Isn't it possible for instance to just merge the backen= d > core (and console/xenfb updates) in Ian's tree first for a start? http://kraxel.fedorapeople.org/patches/qemu-xen/ I didn't touch the build system, it is even more scary than the qemu one alone, I just set CONFIG_XEN unconditionally. I also largely left vl.c as-is, so xend shouldn't need any changes. The -domid switch sets an additional (redundant) variable, to keep the amount of changes as small as possible for now. Also -name and -domain-name are aliased, both set qemu_name and domain_name. In upstream qemu xenpv support is a runtime-switch for the normal qemu, the xen patches leave the qemu-dm target in place. The framebuffer driver probably has some performance regressions. Fixing those depends on the display patches being pushed upstream. > Then you can push your code to qemu, > I guess that could be fine, as you said xen will not need to use e.g. > the block and net backends. blk and net backends are not there (yet). But they should be a nop for xen anyway as long as you don't wind up stuff in xend to put them in use. For the net backend it probably wouldn't be that useful. The block backend should be a good replacement for blktap though and maybe can save you the effort of porting the blktap kernel driver to the pv_ops kernel. cheers, Gerd --=20 http://kraxel.fedorapeople.org/xenner/