Re: Qemu (host) <-> host userspace signaling?

[Avi Kivity <avi@redhat.com>]

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.