pav wrote:
Hello,
I am looking for a simple way to get a bidirectional event notification
interface between qemu/kvm and host userspace processes. Just a "kick",
messages/data not required.
What I basically need is a way to have an interested host process
informed by a custom qemu device that something happened (i.e. after a
MMIO write) and the other way around - to allow similar notifications
from the process to the qemu device. Of course I do not want qemu to
sleep.
Instant reaction to such events is not required.
I understand I could use a unix socket and qemu_chr_open() and friends
for this, but isn't a full-blown socket a bit of an overkill for a simple
"kick" interface?
Not at all. Send a byte to have the other side wake up.
From what I understand qemu would then act as a server and sleep just
after starting (or later?), waiting for connections? Or maybe there is a
way to reverse it, have qemu be the client, although that could still
make qemu sleep?.
I guess it could use some kind of poll/select, but I am not sure where in
qemu should such code be put in though...
You can have have qemu act as a client or as server, and wait for
connections or not.
Or maybe there is something else for this in qemu already? I had thought
iosignalfd or eventfd were made for that, but if I understand correctly,
they communicate with the guest and are for something different?
iosiginalfd and irqfd are slightly more efficient, but you need to make
them available to another process by passing them over a unix domain
socket with SCM_RIGHTS. So they are more cumbersome to set up.
irqfd also requires MSI support in the guest.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
