From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4w3u-0004rw-Vi for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:12:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4w3X-0006aC-EQ for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:12:26 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:35103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4w3X-0006Zv-8D for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:12:03 -0500 Received: by pbcuo5 with SMTP id uo5so5890088pbc.4 for ; Tue, 06 Mar 2012 07:12:01 -0800 (PST) Message-ID: <4F56293C.4040601@codemonkey.ws> Date: Tue, 06 Mar 2012 09:11:56 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F4CBE85.5000006@citrix.com> <4F553C48.8070902@codemonkey.ws> <4F556C3D.3060008@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Qemu disaggregation in Xen environment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "Julien Grall (Intern)" , "xen-devel@lists.xensource.com" , Julian Pidancet , Stefano Stabellini , "qemu-devel@nongnu.org" On 03/06/2012 02:22 AM, Markus Armbruster wrote: > Anthony Liguori writes: > >> My concern is that this moves the Xen use case pretty far from what >> the typical QEMU use case would be (running one emulator per guest). >> >> If it was done in a non-invasive way, maybe it would be acceptable but >> at a high level, I don't see how that's possible. >> >> I almost think you would be better off working to build a second front >> end (reusing the device model, and nothing else) specifically for Xen. >> >> Almost like qemu-io but instead of using the block layer, use the device model. > > What's in it for uses other than Xen? > > I figure a qemu-dev could help us move towards a more explicit interface > between devices and the rest. > > qemu-io is useful for testing. Do you think a qemu-dev could become a > useful testing tool as well? It all depends on how it develops. I think that's the primary advantage of doing a qemu-dev here for Xen. Instead of shoe horning a use-case that really doesn't fit with the model of qemu-system-*, we can look at a new executable that satisfies another use case and potentially use it for other things. The fundamental characteristic of qemu-system-* is "a guest is a single process". That's the defining characteristic to me and all of the global soup we have deeply ingrains that into our design. Trying to turn it into "half a guest is a single process" is going to be horrific. OTOH, I can imagine qemu-dev as simply, "this process exposes a set of devices and an RPC interface to interact with them". That will surely improve modularity, could be useful for testing, and possibly will evolve into something that it useful outside of Xen. Regards, Anthony Liguori >