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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
