From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBwln-0005Fu-9g for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:36:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBwlm-0005Eu-0u for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:36:50 -0500 Received: from [199.232.76.173] (port=50071 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBwll-0005El-L0 for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:36:49 -0500 Received: from mx2.redhat.com ([66.187.237.31]:33644) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBwll-0001SF-4a for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:36:49 -0500 Date: Sun, 14 Dec 2008 21:37:35 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. Message-ID: <20081214193735.GA7215@redhat.com> References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> <49455B5E.8080504@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49455B5E.8080504@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Sun, Dec 14, 2008 at 01:15:42PM -0600, Anthony Liguori wrote: > Gleb Natapov wrote: >> On Sun, Dec 14, 2008 at 02:28:23PM +0200, Blue Swirl wrote: >> >>> On 12/14/08, Gleb Natapov wrote: >>> >>>> There is a need for communication channel between host and various >>>> agents that are running inside a VM guest. The channel will be used >>>> for statistic gathering, logging, cut & paste, host screen resolution >>>> changes notification, guest configuration etc. >>>> >>> Isn't this exactly what the firmware configuration device was supposed >>> to be used for? In the list of use cases you gave, I don't see >>> anything that could not be done with it. >>> >>> >> The requirement for firmware configuration interface was different. We >> wanted something simple that we can use as early as possible in cpu init >> code and performance was not considered at all. Obviously PCI device doesn't >> fit for this. We don't want to write PCI driver inside a BIOS and PCI >> initialization is too late in HW initialization sequence. >> >> The requirement for vmchannel was that it should allow a guest >> to communicate with external (to qemu) process and with reasonable >> performance too. > > This is not a requirement that I think is important. It's only a > requirement for you because you have closed code that you want to > implement the backend with. I would personally be more interested in > vmchannel backends in QEMU and I think there will be a lot of them. > I don't know why do you think that we are going to use that for closed code or something. It will be used by libvirt and it is open source last I checked. -- Gleb.