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

[Daniel P . Berrangé]

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|