From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfXlE-000831-Fc for qemu-devel@nongnu.org; Thu, 01 Sep 2016 15:34:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfXlA-0004gF-Ac for qemu-devel@nongnu.org; Thu, 01 Sep 2016 15:34:51 -0400 Date: Thu, 1 Sep 2016 16:34:45 -0300 From: Eduardo Habkost Message-ID: <20160901193445.GF1151@thinpad.lan.raisama.net> 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> <27ce8661-7e37-9533-cbee-6a0e6daeb165@redhat.com> <20160901173937.GE1151@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160901173937.GE1151@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH] vl: Delay initialization of memory backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, famz@redhat.com, mprivozn@redhat.com, bsd@redhat.com, qemu-stable@nongnu.org, Yang Hongyang , Jason Wang On Thu, Sep 01, 2016 at 02:39:37PM -0300, Eduardo Habkost wrote: > On Thu, Sep 01, 2016 at 05:41:52PM +0200, Paolo Bonzini wrote: > > On 01/09/2016 17:10, Eduardo Habkost wrote: > > > Ouch. It looks like the ordering requirements are messier than I > > > thought. vhost-user depends on the memory backends to be already > > > initialized. > > > > You could also look at delaying initialization of vhost-user, not > > sending anything on the wire until after machine creation. > > I was wishing the bug could be fixed without the need to touch > vhost, but I will take a look. > > BTW, the vhost error is actually happening inside a VCPU thread, > after everything was supposed to be fully initialized. Maybe the > memory listener logic in vhost.c is broken somehow? This is getting hairier. Summary: 1) vhost_user_set_mem_table() fails because dev->mem->nregions is 0 2) dev->mem->nregions is supposed to get new entries based on the memory listener callbacks 3) vhost_region_add() gets called properly, and calls vhost_set_memory(), but: 4) vhost_set_memory() forces add=false if memory_region_get_dirty_log_mask(section->mr) & ~(1 << DIRTY_MEMORY_MIGRATION) (I have no idea why) 5) memory_region_init_ram_from_file() sets: mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0; (I don't understand what are the consequences of this) 6) The tcg_enabled() check above is broken if the memory region is created before configure_accelerator() is called. My patch moves memory backend initialization after configure_accelerator() I'm very confused. My patch seems to fix the dirty_log_mask initialization at (5) by accident? But for some reason this breaks vhost-user and makes it ignore all memory regions if using TCG? (vhost-user-test forces accel=tcg, BTW) As I have no idea why vhost_set_memory() ignores the memory region based on memory_region_get_dirty_log_mask(), I don't know what's supposed to be happening here. Any help would be appreciated. -- Eduardo