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: Rafael David Tinoco
Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism
Date: Tue, 4 Oct 2016 10:29:22 -0300

> On Oct 04, 2016, at 10:10, Marc-André Lureau <address@hidden> wrote:
> 
> > 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.

I was going for that approach. I could have something similar to:

-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/
 

> 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.

But, yes, indeed the vhost_log_shm makes that approach tricky. If sharing the 
same log file with multiple vhost backend. Besides, tools like openstack would 
put all the vhost log files in the same place at the end. 

Having a global config path, forced to be specified, orelse the vhost log isn't 
created, like when it fails nowadays. This seems to be the right approach. 

reply via email to

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