Avi Kivity wrote: > 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'll just add that you could tie the irqfd to an iosignalfd to eliminate the involvement of qemu on either side as well. I'm not sure if that really works with the design of this particular device (e.g. perhaps qemu is needed for other reasons besides signaling), but it is a neat demonstration of the flexibility of the newly emerging kvm-eventfd interfaces. -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
