From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBqlS-0000MD-4F for qemu-devel@nongnu.org; Sun, 14 Dec 2008 08:12:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBqlP-0000JM-Qz for qemu-devel@nongnu.org; Sun, 14 Dec 2008 08:12:04 -0500 Received: from [199.232.76.173] (port=55231 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBqlP-0000JJ-Nr for qemu-devel@nongnu.org; Sun, 14 Dec 2008 08:12:03 -0500 Received: from mx2.redhat.com ([66.187.237.31]:49246) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBqlP-0006ev-Cj for qemu-devel@nongnu.org; Sun, 14 Dec 2008 08:12:03 -0500 Date: Sun, 14 Dec 2008 15:12:47 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. Message-ID: <20081214131247.GS5555@redhat.com> References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm@vger.kernel.org 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. Firmware interface that copies data byte at time does not fit. And obviously firmware interface lacks interrupts, we don't want to poll for data in a guest. > So, to avoid duplicated functionality, I'd add the missing pieces to > the configuration device and if PCI compatibility is desired, the > firmware configuration device IO port could be handled by a wrapper > PCI device much like what you proposed. > vmchannel code uses virtio subsistem (which was not present in qemu when firmware interface was added BTW). Theoretically we can use virtio for FW interface too, but the in guest part of vitio is too complex to be added to firmware IMO. Lets keep simple things simple. -- Gleb.