Re: [PATCH 0/2] RFC: add -mem-shared option

[Marc-André Lureau]

On Fri, Nov 29, 2019 at 1:42 PM Daniel P. Berrangé <address@hidden> 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é <address@hidden> 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 <address@hidden> 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.