Hi
On Fri, Oct 21, 2016 at 6:03 AM Rafael David Tinoco <
rafael.tin...@canonical.com> wrote:
> Judging by the outputs above, looks like vhost_dev_log_is_shared is
> returning false, making (2) - vhost_dev_start - to use a different log
> allocation (malloc) than the one that was tested for allowi
Hello Again, finally I could get back to this, and..
I was finishing a patch creating the open+truncate+mmap+unlink mechanism on
files specified by "vhostlog" parameter of tap devices. Patch is done, problem
is that... looks like the "memfd" is only used for shared logs AND vhost-net
(used for
The correct (and draft) one:
http://pastebin.ubuntu.com/23357210/
Im passing vhostlog parameter as "hdev->log_filename" so it can be accessed
from net_init_tap()-> functions AND from vhost_dev_start()-> functions. This
way I don't have to change function prototypes anymore.
> On Oct 21, 2016, a
> On Oct 04, 2016, at 10:50, Marc-André Lureau
> wrote:
>
> What about having a single config parameter as a place to put all vhost logs
> for all drives for a single instance ? Remove the memfd implementation with
> all the memfd shared_memory option ? Replace it with a
> open+unlink+ftrunc
On Tue, Oct 4, 2016 at 5:34 PM Rafael David Tinoco <
rafael.tin...@canonical.com> wrote:
> True.
>
> What about having a single config parameter as a place to put all vhost
> logs for all drives for a single instance ? Remove the memfd implementation
> with all the memfd shared_memory option ? Rep
Hi
On Tue, Oct 4, 2016 at 5:25 PM Daniel P. Berrange
wrote:
> On Tue, Oct 04, 2016 at 01:10:17PM +, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange
> > wrote:
> >
> > > On Tue, Oct 04, 2016 at 12:39:17PM +, Marc-André Lureau wrote:
> > > > Hi Ra
> On Oct 04, 2016, at 10:10, Marc-André Lureau
> 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
> > leavin
True.
What about having a single config parameter as a place to put all vhost logs
for all drives for a single instance ? Remove the memfd implementation with all
the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap
approach only.
This way every device would get its o
On Tue, Oct 04, 2016 at 01:10:17PM +, Marc-André Lureau wrote:
> Hi
>
> On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange
> wrote:
>
> > On Tue, Oct 04, 2016 at 12:39:17PM +, Marc-André Lureau wrote:
> > > Hi Rafael, Daniel,
> > >
> > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco
Hi
On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange
wrote:
> On Tue, Oct 04, 2016 at 12:39:17PM +, Marc-André Lureau wrote:
> > Hi Rafael, Daniel,
> >
> > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco <
> > rafael.tin...@canonical.com> wrote:
> >
> > > Let me work on it. I'll get back
On Tue, Oct 04, 2016 at 12:39:17PM +, Marc-André Lureau wrote:
> Hi Rafael, Daniel,
>
> On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco <
> rafael.tin...@canonical.com> wrote:
>
> > Let me work on it. I'll get back soon.
> >
> >
> thanks for working on it, before that I have a few question
Hi Rafael, Daniel,
On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco <
rafael.tin...@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:
> >
> >
Let me work on it. I'll get back soon.
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 wrote:
>> Yes, definitely. Check this:
>
> [snip]
>
> So in that case, I think we must add ability to specify an explici
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.
> > On Oct 03, 2016, at 15:46, Rafael David Ti
Yes, definitely. Check this:
/**
* @qemu_chr_fe_set_msgfds:
*
* For backends capable of fd passing, set an array of fds to be passed with
* the next send operation.
* A subsequent call to this function before calling a write function will
* result in overwriting the fd array with the new val
Hello Daniel,
> On Oct 03, 2016, at 14:55, Daniel P. Berrange wrote:
>
>> Well, it unlinks the file but the references are still there while the
>> descriptor isn't closed by this process, or by the one that receives the
>> descriptor (that is why is the "unlink" so early).
>>
>> If you check v
On Mon, Oct 03, 2016 at 03:41:10PM -, Rafael David Tinoco wrote:
> Sorry, I was only able to come back to this today.
>
> > On Sep 27, 2016, at 09:18, Daniel Berrange <1626...@bugs.launchpad.net>
> > wrote:
> >
> >> There are numerous people relying on older kernels in openstack
> >> deploy
Sorry, I was only able to come back to this today.
> On Sep 27, 2016, at 09:18, Daniel Berrange <1626...@bugs.launchpad.net> wrote:
>
>> There are numerous people relying on older kernels in openstack
>> deployments - sometimes with specific drivers (ovswitch, dpdk,
>> infiniband) holding kerne
On Tue, Sep 27, 2016 at 11:01:10AM -, Rafael David Tinoco wrote:
> > On Sep 27, 2016, at 05:36, Daniel P. Berrange wrote:
> >
> > On Tue, Sep 27, 2016 at 03:06:21AM +, Rafael David Tinoco wrote:
> >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback
> >> mechanism for syst
19 matches
Mail list logo
