qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Vmchannel PCI device.


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device.
Date: Sun, 14 Dec 2008 13:15:42 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Gleb Natapov wrote:
On Sun, Dec 14, 2008 at 02:28:23PM +0200, Blue Swirl wrote:
On 12/14/08, Gleb Natapov <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]