From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KEsoh-0005mQ-W6 for qemu-devel@nongnu.org; Fri, 04 Jul 2008 17:27:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KEsog-0005lq-CE for qemu-devel@nongnu.org; Fri, 04 Jul 2008 17:27:43 -0400 Received: from [199.232.76.173] (port=41012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KEsog-0005lj-4R for qemu-devel@nongnu.org; Fri, 04 Jul 2008 17:27:42 -0400 Received: from wf-out-1314.google.com ([209.85.200.169]:45474) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KEsog-0001Pf-60 for qemu-devel@nongnu.org; Fri, 04 Jul 2008 17:27:42 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1324583wfd.4 for ; Fri, 04 Jul 2008 14:27:40 -0700 (PDT) Message-ID: <5d6222a80807041427t5510c2f5y172b3674697728ef@mail.gmail.com> Date: Fri, 4 Jul 2008 18:27:40 -0300 From: "Glauber Costa" In-Reply-To: <20080704213844.GB29672@tapir> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d6222a80807041340j367cfe3ah67a9d771caa0ee63@mail.gmail.com> <20080704213844.GB29672@tapir> Subject: [Qemu-devel] Re: QEMU Accel - git tree Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carlo Marcelo Arenas Belon Cc: Chris Wright , Hollis Blanchard , kvm@vger.kernel.org, Jes Sorensen , qemu-devel@nongnu.org On Fri, Jul 4, 2008 at 6:38 PM, Carlo Marcelo Arenas Belon wrote: > On Fri, Jul 04, 2008 at 05:40:03PM -0300, Glauber Costa wrote: >> Hey Folks >> >> I'm publishing a git repository for the QEMU Accel patches. It lives at >> >> git://git.kernel.org/pub/scm/virt/qemu/glommer/qemu-accel.git > > for the few of us that had been living under a rock, could you give an > explanation on what is QEMU Accel and why we need one? Sure. Currently, kqemu and kvm (not to mention xen, about which I don't really know about in this case), use a different user <-> kernel interface. Support for them in qemu requires all of them to spread code throughout core qemu, negatively affecting readability, maintainability, all the other sorts of *bilities. One of the sad aspects of it, is that it makes an possible inclusion of kvm in the qemu code base much harder to happen, making us maintain our own "fork" tree. (Xen has the same issue). The QEMUAccel patchset is an effort to put wrappers in strategic places throughout qemu code, so any accelerator (kqemu, kvm, xen, yourown) can register itself, and tell qemu how to do specific operations. Talking to hollis last week, he pointed out that a better solution would be to make all of them to use the same kernel interface. It's a valid approach, but I believe an user-space interface would be more flexible. That's why I'm still maintaining this set (now in tree-form ;-) ) (sorry hollis, should have cc'd you in the first message here, but forgot). > google bounced me back to the a broken link in the qemu homepage that doesn't > have a reference to it, and also showed some patches which seem to be trying > to abstract kqemu and kvm which I presume are part of this git tree. Yes, exactly. > > how is this mean to fit on a qemu or kvm installation, and if its main > objective is to be able to have a version of qemu compiled with support for > both kvm and kqemu accelerators, is it at least feature complete enough to > have that working and let you select which one to use?, under which > circumstances? As I said, the kvm code is PoC. I don't plan to start working seriously on it until there's agreement on the interfaces here, at least a basic one. kqemu should be running fine. (WFM) The kvm code, however, do work with limited functionality. The functionalities it lacks are: * stability ;-) * smp * userspace pit and irqchip -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."