qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vhost-user question


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] vhost-user question
Date: Thu, 1 Feb 2018 10:30:27 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

* jack.chen (address@hidden) wrote:
> Thanks,But my question is how the fd belonging to qemu can be used in
> another process such as DPDK?is fd just effective within one process?
> for example ,if process A open file a.txt,and it gets one fd。the fd
> can only be used in process A ,can it be used in process B?

Both processes can use the fd - but it needs a trick.
Unix sockets can pass fd's between processes - so you pass the fd down
the socket and it's received on the destination - the number the fd gets
is different on the two processes, but ti still represents the same
underlying fd on the same file.

Follow the call to vhost_user_write in vhost_user_set_mem_table you see
it takes the 'fds' array, that eventually gets passed over the unix
socket.

Dave

> 2018-02-01 17:51 GMT+08:00 Dr. David Alan Gilbert <address@hidden>:
> > * jack.chen (address@hidden) wrote:
> >> thanks,but I really can not understand how the fd works,can someone
> >> explain it or give me some  reference material??
> >
> > Probably the man page for the mmap system call, or an introduction to
> > linux/unix syscalls.  Just remember that any shared memory will be
> > 'backed' by a file (or something that works like a file), and if it's a
> > file, when you open it you get a file descriptor.  Once you have that fd
> > you can map it somewhere else.
> >
> > Dave
> >
> >>
> >> 2018-02-01 1:31 GMT+08:00 Dr. David Alan Gilbert <address@hidden>:
> >> > * jack.chen (address@hidden) wrote:
> >> >> hello,I am confused when I read vhost-user source code in qemu.I know
> >> >> vhost-user app shared memory with qemu by mmap,but why it can use fd 
> >> >> which
> >> >> is belong to qemu?
> >> >> relative code:
> >> >>  qemu code in function vhost_user_set_mem_table
> >> >> fd = memory_region_get_fd(mr);
> >> >>         if (fd > 0) {
> >> >>             msg.payload.memory.regions[fd_num].userspace_addr =
> >> >> reg->userspace_addr;
> >> >>             msg.payload.memory.regions[fd_num].memory_size  =
> >> >> reg->memory_size;
> >> >>             msg.payload.memory.regions[fd_num].guest_phys_addr =
> >> >> reg->guest_phys_addr;
> >> >>             msg.payload.memory.regions[fd_num].mmap_offset = offset;
> >> >>             assert(fd_num < VHOST_MEMORY_MAX_NREGIONS);
> >> >>             fds[fd_num++] = fd;
> >> >>         }
> >> >>
> >> >> ……
> >> >> DPDK code in vhost_user_set_mem_table
> >> >>
> >> >> mmap_addr = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
> >> >> MAP_SHARED | MAP_POPULATE, fd, 0);
> >> >> ……
> >> >>
> >> >> thanks a lot!
> >> >
> >> > Because that's how the dpdk/vhost-user binary knows what to mmap;
> >> > each fd corresponds to the backing file of the memory area that's being
> >> > shared.  This way the dpdk/vhost doesn't need to open those files itself
> >> > or try and match the exact memory configuration of qemu; QEMU just gives
> >> > it the exact thing it needs to mmap - which is just the fd and offsets.
> >> >
> >> > Dave
> >> >
> >> > --
> >> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]