From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiKyr-0000kZ-RR for qemu-devel@nongnu.org; Tue, 22 Mar 2016 08:00:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiKyo-0000EQ-Jx for qemu-devel@nongnu.org; Tue, 22 Mar 2016 08:00:13 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:41876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiKyo-0000Cy-Be for qemu-devel@nongnu.org; Tue, 22 Mar 2016 08:00:10 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 Mar 2016 12:00:06 -0000 Date: Tue, 22 Mar 2016 12:59:58 +0100 From: Cornelia Huck Message-ID: <20160322125958.13afc4e7.cornelia.huck@de.ibm.com> In-Reply-To: <56F11492.5040103@redhat.com> References: <56E93A22.1080102@de.ibm.com> <56E93ECE.10103@redhat.com> <56E9425C.8030201@de.ibm.com> <56E957AD.2050005@redhat.com> <56E961EA.4090908@de.ibm.com> <56E9638B.5090204@redhat.com> <20160317003906.GA23821@ad.usersys.redhat.com> <56EA8EEE.2020801@linux.vnet.ibm.com> <20160321105718.GA7710@ad.usersys.redhat.com> <56F0EFCA.4080003@linux.vnet.ibm.com> <20160322071804.GC24999@ad.usersys.redhat.com> <20160322100706.597dab1b.cornelia.huck@de.ibm.com> <56F11492.5040103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Fam Zheng , qemu-block@nongnu.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Christian Borntraeger , tu bo , Stefan Hajnoczi On Tue, 22 Mar 2016 10:46:58 +0100 Paolo Bonzini wrote: > On 22/03/2016 10:07, Cornelia Huck wrote: > > So far, we had the best results with my refactoring + the mutex/bh > > change. Two problems: > > > > - We don't really understand yet why my refactoring helps, but passing > > the assign value is a good canditate (and it's agreed that this fixes a > > bug, I think.) > > - There's some problem with the bh, if I understood Stefan correctly. > > They can be fixed with just an extra object_ref/object_unref. > > I didn't understand that Tu Bo also needed the BH fix, and with that > information it makes sense. Passing the assign value ensures that > ioeventfd remains always assigned. With the CPU threads out of the > picture, the BH becomes enough to make everything thread-safe. Yes, this makes sense. Might we still have a hole somewhere in dataplane teardown? Probably not, from reading the code, even if it runs in cpu thread context.