On Fri, Nov 29, 2019 at 1:42 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Fri, Nov 29, 2019 at 01:31:11PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Fri, Nov 29, 2019 at 1:27 PM Daniel P. Berrangé <berra...@redhat.com> > > wrote: > > > > > > On Fri, Nov 29, 2019 at 11:30:51AM +0400, Marc-André Lureau wrote: > > > > Hi > > > > > > > > On Fri, Nov 29, 2019 at 11:03 AM Gerd Hoffmann <kra...@redhat.com> > > > > wrote: > > > > > > > > > > On Thu, Nov 28, 2019 at 06:15:16PM +0400, Marc-André Lureau wrote: > > > > > > Hi, > > > > > > > > > > > > Setting up shared memory for vhost-user is a bit complicated from > > > > > > command line, as it requires NUMA setup such as: m 4G -object > > > > > > memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa > > > > > > node,memdev=mem. > > > > > > > > > > > > Instead, I suggest to add a -mem-shared option for non-numa setups, > > > > > > that will make the -mem-path or anonymouse memory shareable. > > > > > > > > > > Is it an option to just use memfd by default (if available)? > > > > > > > > Yes, with a fallback path currently using a temporary file under /tmp > > > > (we may want to use shm_open() instead, or a different location such > > > > as XDG_RUNTIME_DIR? - and use O_TMPFILE) > > > > > > We can't assume either /tmp or XDG_RUNTIME_DIR is on tmpfs as that is no > > > where near standard across all OS distros, and even if on tmpfs these > > > dirs can be size limited to a significant subset of available RAM. IOW > > > we can't safely use them unless explicitly told to. > > > > Is shm_open() acceptable instead? > > > > Imho, -mem-shared should do a best effort by default, but can fail. > > Possibly, but if we're relying on shm_open choosing the path, then > its harder for users to know what files to clean up when QEMU crashes > or otherwise exits wthout a shm_unlink
True, although I think you can call shm_unlink() right after shm_open() that should limit the risk of those forgotten files.
