Gleb Natapov wrote:
On Sun, Dec 14, 2008 at 02:28:23PM +0200, Blue Swirl wrote:
On 12/14/08, Gleb Natapov <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
