From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brPj3-0003mp-BC for qemu-devel@nongnu.org; Tue, 04 Oct 2016 09:25:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brPiy-0003Ae-7D for qemu-devel@nongnu.org; Tue, 04 Oct 2016 09:25:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brPix-0003AA-S5 for qemu-devel@nongnu.org; Tue, 04 Oct 2016 09:25:36 -0400 Date: Tue, 4 Oct 2016 14:25:30 +0100 From: "Daniel P. Berrange" Message-ID: <20161004132530.GK5578@redhat.com> Reply-To: "Daniel P. Berrange" References: <20160927121841.GM3967@redhat.com> <3F76E640-1E36-4C4A-8BB9-1DD1EF602FEF@canonical.com> <20161003175539.GO13491@redhat.com> <20161004083628.GB5578@redhat.com> <20161004124228.GI5578@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: Rafael David Tinoco , Bug 1626972 <1626972@bugs.launchpad.net>, qemu-devel On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-Andr=C3=A9 Lureau wrote: > Hi >=20 > On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange > wrote: >=20 > > On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-Andr=C3=A9 Lureau wrot= e: > > > Hi Rafael, Daniel, > > > > > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < > > > rafael.tinoco@canonical.com> 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 > > > > wrote: > > > > > > > > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco w= rote: > > > > >> Yes, definitely. Check this: > > > > > > > > > > [snip] > > > > > > > > > > So in that case, I think we must add ability to specify an expl= icit > > path > > > > > that apps can use *regardles* of whether memfd support exists o= r not. > > > > > > > > > > How will this path be used? Is it going to be global to qemu for va= rious > > > use (kinda like $TMP), or per-device, or for memfd fallback only? S= hould > > > the path pre-exist? (I suppose, if not, qemu should clean it up whe= n > > > leaving) > > > > I'd expect it to be an option set against the vhost user backend, sin= ce > > that's the thing using this. > > > > If other things have similar usage needs wrt memfd in future, they wo= uld > > also need similar path config option. > > >=20 > 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 proces= s. While that may be the common case today, it doesn't feel like a reasonabl= e 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 --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr= / :|