qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fal


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism
Date: Tue, 4 Oct 2016 14:25:30 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <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 <
> > > 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 <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.

Hmm, is there a reason why it is shared? That seems to make an assumption
that all vhost-user backends would be managed by the same external process.
While that may be the common case today, it doesn't feel like a reasonable
assumption to make long term. IOW it feels wiser to have it set per-NIC
unless I'm missing something important that means it must be shared ?

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/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]