From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. Date: Sun, 14 Dec 2008 13:15:42 -0600 Message-ID: <49455B5E.8080504@codemonkey.ws> References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from an-out-0708.google.com ([209.85.132.250]:5627 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751250AbYLNTPr (ORCPT ); Sun, 14 Dec 2008 14:15:47 -0500 Received: by an-out-0708.google.com with SMTP id d40so988006and.1 for ; Sun, 14 Dec 2008 11:15:46 -0800 (PST) In-Reply-To: <20081214131247.GS5555@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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