Comment 21 for bug 1626972

Revision history for this message
elmarco (marcandre-lureau) wrote : Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

Hi

On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden>
wrote:

> On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote:
> > Hi Rafael, Daniel,
> >
> > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco <
> > <email address hidden>> wrote:
> >
> > > Let me work on it. I'll get back soon.
> > >
> > >
> > thanks for working on it, before that I have a few questions:
> >
> > Tks Daniel.
> > >
> > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden>
> > > wrote:
> > > >
> > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote:
> > > >> Yes, definitely. Check this:
> > > >
> > > > [snip]
> > > >
> > > > So in that case, I think we must add ability to specify an explicit
> path
> > > > that apps can use *regardles* of whether memfd support exists or not.
> > >
> >
> > How will this path be used? Is it going to be global to qemu for various
> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should
> > the path pre-exist? (I suppose, if not, qemu should clean it up when
> > leaving)
>
> I'd expect it to be an option set against the vhost user backend, since
> that's the thing using this.
>
> If other things have similar usage needs wrt memfd in future, they would
> also need similar path config option.
>

The log may be shared if there are several vhost-user (stored in
vhost_log_shm global), so I think it makes more sense to have a global
config path for it, or you may end up duplicating that information per
vhost backend and having files in either of the specified paths.

>
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org -o- http://virt-manager.org
> :|
> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/
> :|
>
--
Marc-André Lureau