From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfhjA-0007sr-Mo for qemu-devel@nongnu.org; Fri, 02 Sep 2016 02:13:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfhj6-0007bl-9v for qemu-devel@nongnu.org; Fri, 02 Sep 2016 02:13:23 -0400 From: Markus Armbruster References: <1472674630-18886-1-git-send-email-ehabkost@redhat.com> <20160831214625.373180.83128@ex-std-node742.prod.rhcloud.com> <20160901151030.GC1151@thinpad.lan.raisama.net> Date: Fri, 02 Sep 2016 08:13:17 +0200 In-Reply-To: <20160901151030.GC1151@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Thu, 1 Sep 2016 12:10:30 -0300") Message-ID: <87poomg77m.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] vl: Delay initialization of memory backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, famz@redhat.com, mprivozn@redhat.com, Jason Wang , qemu-stable@nongnu.org, bsd@redhat.com, pbonzini@redhat.com, Yang Hongyang Eduardo Habkost writes: > 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. As discussed before, there are two workable ways to process the command line: strictly left to right (leave ordering to the user), and "do the right thing" (order of options doesn't matter). Of course, we do neither. We kind of try to do the right thing, by adding special cases whenever we get bitten. Order doesn't matter, except when it does, and things work, except when they don't. Reordering your command line may or may not get it to work. Fails the basic interface taste test: would explaining it in plain English be impractical and/or embarrassing? How to best get out of this self-dug hole isn't obvious. Switching to strictly left to right will break some command lines. Making order truly not matter looks hard, because the dependencies are complex and not well understood.