From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dk4rx-0002ET-Tq for qemu-devel@nongnu.org; Tue, 22 Aug 2017 04:49:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dk4ru-0005fH-Ry for qemu-devel@nongnu.org; Tue, 22 Aug 2017 04:49:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53628) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dk4ru-0005bw-LE for qemu-devel@nongnu.org; Tue, 22 Aug 2017 04:49:02 -0400 Date: Tue, 22 Aug 2017 09:48:55 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20170822084855.GC2109@work-vm> References: <1503301464-27886-1-git-send-email-peterx@redhat.com> <20170821085851.GA4371@lemon> <20170821100555.GC30356@pxdev.xzpeter.org> <20170821135743.GC4371@lemon> <20170821153622.GG2231@work-vm> <20170821165450.GE4371@lemon> <20170821172852.GA3236@work-vm> <20170822021556.GA2146@lemon> <20170822025654.GE30356@pxdev.xzpeter.org> <20170822041519.GC2146@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822041519.GC2146@lemon> Subject: Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Peter Xu , Laurent Vivier , Juan Quintela , Markus Armbruster , mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, Paolo Bonzini * Fam Zheng (famz@redhat.com) wrote: > On Tue, 08/22 10:56, Peter Xu wrote: > > I haven't really encountered (c), but I think it's the migrate_cancel > > command that matters, which should not need BQL as well. > > There is bdrv_invalidate_cache_all() in migrate_cancel which clearly isn't safe. > Is that if block unreachable in this case? If so we should assert, otherwise > this command is not okay to run without BQL. Hmm yes that's a fairly recent addition to migrate_cancel - it used to be a simplish shutdown(); still I think it must be possible to get back to a simple shutdown() which is run directly with the cache stuff perhaps coming along later; actually the tricky bit is that the fd for the shutdown() isn't just a simple int, but is in an object which we have to make sure doesn't get freed while we do it. > Generically, what guarantee the thread-safety of a qmp command when you decide > BQL is not needed? In other words, how do you prove commands are safe without > BQL? I think almost every command accesses global state, but lock-free data > structures are rare AFAICT. I'm assuming there would initially be very few commands marked as lock-free, that were mostly trivially small. I was thinking that it might be possible to do a debug build with some checking as well; something like making the code that takes the bql check a per-thread flag, and assert if the flag is set. The monitor-threads could set the flag, so that if we fell down a path that tried to take the BQL we'd fail. Dave > Fam -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK