Qemu (host) <-> host userspace signaling?

Qemu (host) <-> host userspace signaling?

[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?
>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

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

[Avi Kivity]

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.

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

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

Avi Kivity wrote:
> pav wrote:
>>
>>
>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

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

[Avi Kivity]

Gregory Haskins wrote:
> Avi Kivity wrote:
>   
>> pav wrote:
>>     
>>> 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).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.