From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LBq5G-0008Vs-1Y
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 07:28:30 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LBq5D-0008Vg-LL
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 07:28:28 -0500
Received: from [199.232.76.173] (port=57306 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LBq5D-0008Vd-FW
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 07:28:27 -0500
Received: from mail-bw0-f12.google.com ([209.85.218.12]:41394)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1LBq5C-0002Yz-SM
	for qemu-devel@nongnu.org; Sun, 14 Dec 2008 07:28:27 -0500
Received: by bwz5 with SMTP id 5so3646072bwz.10
	for <qemu-devel@nongnu.org>; Sun, 14 Dec 2008 04:28:23 -0800 (PST)
Message-ID: <f43fc5580812140428j15fa8064iee1224b0013ab3e6@mail.gmail.com>
Date: Sun, 14 Dec 2008 14:28:23 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device.
In-Reply-To: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org

On 12/14/08, Gleb Natapov <gleb@redhat.com> 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.

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.