Qemu (host) <-> host userspace signaling?
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?
Quoted 1 line
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...
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?
I would be very greatful for your help.
Best regards,
Pav
Quoted 11 lines · pav
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Quoted 9 lines · Avi Kivity
Quoted 6 lines · pav
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.
FWIW: you could also use an eventfd here.
-Greg
Quoted 4 lines · Gregory Haskins
Quoted 2 lines · Avi Kivity
pav wrote:
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
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.
FWIW: you could also use an eventfd here.
To share the eventfd with someone else you need a unix domain socket anyway. Once you do that setup, however, it works out quite nicely (esp. if it's connected to iosignalfd).
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.