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

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov wrote:
> On Sun, Dec 14, 2008 at 02:28:23PM +0200, Blue Swirl wrote:
>   
>> 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.
>>
>>     
> 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