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: Marc-André Lureau
Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism
Date: Tue, 04 Oct 2016 13:46:33 +0000

Hi

On Tue, Oct 4, 2016 at 5:25 PM Daniel P. Berrange <address@hidden>
wrote:

> 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 ?
>
>
It's a shared log, just like they share the same ram. Duplicating the log
would mostly make migration more difficult to handle and increase a bit
memory usage.


> 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


reply via email to

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