Re: [PATCH v2] Shared memory device with interrupt support

[Avi Kivity <avi@redhat.com>]

Cam Macdonell wrote:
>>
>> If my understanding is correct both the VM's who wants to communicate 
>> would gives this path in the command line with one of them specifying 
>> as "server".
>
> Exactly, the one with the "server" in the parameter list will wait for 
> a connection before booting.

hm, we may be able to eliminate the server from the fast path, at the 
cost of some complexity.

When a guest connects to the server, the server creates an eventfd and 
passes using SCM_RIGHTS to all other connected guests.  The server also 
passes the eventfds of currently connected guests to the new guest.  
 From now on, the server does not participate in anything; when a quest 
wants to send an interrupt to one or more other guests, its qemu just 
writes to the eventfds() of the corresponding guests; their qemus will 
inject the interrupt, without any server involvement.

Now, anyone who has been paying attention will have their alarms going 
off at the word eventfd.  And yes, if the host supports irqfd, the 
various qemus can associate those eventfds with an irq and pretty much 
forget about them.  When a qemu triggers an irqfd, the interrupt will be 
injected directly without the target qemu's involvement.

I like it.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.