[Qemu-devel] Passing fds through a qemu char device

[Qemu-devel] Passing fds through a qemu char device

[Cam Macdonell]

Hi,

I'm trying to pass eventfds between qemu processes and I'm trying to use 
a qemu char device to do this.  AFAICT with a qemu_chr_device the 
polling handler only has support to call read()/write(), not 
send/recvmsg() which are necessary to send and receive fds with 
SCM_RIGHTS through the socket.  Is this true or is there support in Qemu 
for recvmsg() that I'm not seeing?

If not, some options I can see are to add qemu support for 
qemu_chr_recvmsg() to call on the char device.  Or I can simply manage 
the socket outside of qemu_chr_device, but the polling is helpful for 
notifications and I'd prefer to leverage qemu's existing support for that.

Thanks,
Cam

Re: [Qemu-devel] Passing fds through a qemu char device

[Anthony Liguori]

Cam Macdonell wrote:
>
> Hi,
>
> I'm trying to pass eventfds between qemu processes and I'm trying to 
> use a qemu char device to do this.  AFAICT with a qemu_chr_device the 
> polling handler only has support to call read()/write(), not 
> send/recvmsg() which are necessary to send and receive fds with 
> SCM_RIGHTS through the socket.  Is this true or is there support in 
> Qemu for recvmsg() that I'm not seeing?

The TCP/Unix implementations for CharDriverState use send/recv.  You can 
convert the recv path to always use recvmsg() and introduce an 
qemu_chr_ioctl() to pass/recv fds.

You can be smart about storing the recv'd fd in the char driver state 
and that would allow qemu_chr_ioctl(CHR_IOCTL_GET_FD) to not block.  
qemu_chr_ioctl(CHR_IOCTL_SET_FD) would set the fd to be sent for the 
next qemu_chr_write() operation.

Just a thought, other interfaces could also work.

Regards,

Anthony Liguori

Re: [Qemu-devel] Passing fds through a qemu char device

[Cam Macdonell]

Anthony Liguori wrote:
> Cam Macdonell wrote:
>>
>> Hi,
>>
>> I'm trying to pass eventfds between qemu processes and I'm trying to 
>> use a qemu char device to do this.  AFAICT with a qemu_chr_device the 
>> polling handler only has support to call read()/write(), not 
>> send/recvmsg() which are necessary to send and receive fds with 
>> SCM_RIGHTS through the socket.  Is this true or is there support in 
>> Qemu for recvmsg() that I'm not seeing?
> 
> The TCP/Unix implementations for CharDriverState use send/recv.  You can 
> convert the recv path to always use recvmsg() and introduce an 
> qemu_chr_ioctl() to pass/recv fds.

If I understand you correctly, you are suggesting replacing recv() with 
recvmsg() for all qemu char devices?  I would prefer a way to change a 
particular char device to use recvmsg instead of recv, and then create 
qemu_chr_device out of the received fds as needed.  I think this would 
minimize the changes to the existing char device code.  Currently, I 
can't see how to change to recvmsg for an individual char device without 
changing tcp_chr_read(void * opaque) in qemu-char.c (which would affect 
all tcp char devices).

> You can be smart about storing the recv'd fd in the char driver state 
> and that would allow qemu_chr_ioctl(CHR_IOCTL_GET_FD) to not block.  
> qemu_chr_ioctl(CHR_IOCTL_SET_FD) would set the fd to be sent for the 
> next qemu_chr_write() operation.

My goal is to support receiving several fds to support eventfd 
notification between multiple guests (the list of fds would come from an 
external server).  As I mentioned, I would like the qemu process to 
create additonal char devices for each recv'd fd as this would save 
modifying the char driver state.

> 
> Just a thought, other interfaces could also work.
> 

Thanks, it is helpful.

Cam