On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: > Commit 31190ed7 added a migration blocker in vhost_dev_init() to > check if memfd would succeed. It is better if this blocker first > checks if vhost backend requires shared log. This will avoid a > situation where a blocker is added inappropriately (e.g. shared > log allocation fails when vhost backend doesn't support it). Sounds like a bugfix but I'm not sure. Can this part be split out in a patch by itself? > Commit: 35f9b6e added a fallback mechanism for systems not supporting > memfd_create syscall (started being supported since 3.17). > > Backporting memfd_create might not be accepted for distros relying > on older kernels. Nowadays there is no way for security driver > to discover memfd filename to be created: /memfd-XXXXXX. > > Also, because vhost log file descriptors can be passed to other > processes, after discussion, we thought it is best to back mmap by > using files that can be placed into a specific directory: this commit > creates "vhostlog" argv parameter for such purpose. This will allow > security drivers to operate on those files appropriately. > > Argv examples: > > -netdev tap,id=net0,vhost=on > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log > -netdev tap,id=net0,vhost=on,vhostlog=/tmp > > For vhost backends supporting shared logs, if vhostlog is non-existent, > or a directory, random files are going to be created in the specified > directory (or, for non-existent, in tmpdir). If vhostlog is specified, > the filepath is always used when allocating vhost log files. When vhostlog is not specified, can we just use memfd as we did? > Signed-off-by: Rafael David Tinoco