From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBwRQ-0005HP-Li for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:15:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBwRP-0005GZ-1o for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:15:48 -0500 Received: from [199.232.76.173] (port=57734 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBwRO-0005GV-Ty for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:15:46 -0500 Received: from yx-out-1718.google.com ([74.125.44.154]:5149) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBwRO-0007Dg-Lw for qemu-devel@nongnu.org; Sun, 14 Dec 2008 14:15:46 -0500 Received: by yx-out-1718.google.com with SMTP id 3so1080982yxi.82 for ; Sun, 14 Dec 2008 11:15:46 -0800 (PST) Message-ID: <49455B5E.8080504@codemonkey.ws> Date: Sun, 14 Dec 2008 13:15:42 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> In-Reply-To: <20081214131247.GS5555@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org 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. But the firmware config interface is different than what is proposed here in a number of important ways. The first is that this is a streaming communication mechanism verses a value/pair store. It maps naturally to userspace via a socket abstraction and is present in a number of other hypervisors (XenSocket in Xen, VMCI in VMware, etc.). I see the firmware config as more akin to a device tree or CMOS than a generic guest<=>host transport. Regards, Anthony Liguori