On 01.09.2016 17:10, Eduardo Habkost wrote: > On Wed, Aug 31, 2016 at 02:47:21PM -0700, > no-re...@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)? Michal
