Re: [Qemu-devel] [PATCH] vl: Delay initialization of memory backends

[Eduardo Habkost <ehabkost@redhat.com>]

On Thu, Sep 01, 2016 at 06:52:42PM +0200, Michal Privoznik wrote:
> On 01.09.2016 17:10, Eduardo Habkost wrote:
> > On Wed, Aug 31, 2016 at 02:47:21PM -0700, no-reply@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> > [...]
> >> GTESTER check-qtest-x86_64
> >> qemu-system-x86_64: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
> >> qemu-system-x86_64: vhost_set_mem_table failed: Success (0)
> > [...]
> >> **
> >> ERROR:/tmp/qemu-test/src/tests/vhost-user-test.c:149:wait_for_fds: assertion failed: (s->fds_num)
> > 
> > Ouch. It looks like the ordering requirements are messier than I
> > thought. vhost-user depends on the memory backends to be already
> > initialized.
> > 
> > We can't use early initialization because prealloc delays chardev
> > init too much. We can't delay initialization because it is done
> > after netdevs.
> > 
> > We _really_ need to change this to simply use the ordering used
> > on the command-line/config instead of hardcoding messy ordering
> > requirements, but I wouldn't like to wait for a QemuOpts
> > refactoring to fix the bug. I will take a look at the memory
> > regions initialization path, and try to trigger the
> > memory-backend prealloc code there.
> > 
> 
> What I don't understand here is, if kernel already has a pool of
> hugepages from which qemu tries to allocate some, why does allocation
> take up to 1 minute? I would understand if it was during building of the
> pool, but once those pages are reserved allocating them should take no
> time. Isn't this a problem in kernel (too)?

I believe the pages are reserved, but are zeroed when actually
allocated by userspace.

-- 
Eduardo