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