From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLZkx-0008PL-QA for qemu-devel@nongnu.org; Tue, 09 Oct 2012 09:22:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLZkr-00039K-83 for qemu-devel@nongnu.org; Tue, 09 Oct 2012 09:21:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLZkq-00038z-U3 for qemu-devel@nongnu.org; Tue, 09 Oct 2012 09:21:49 -0400 Message-ID: <507424E5.4060705@redhat.com> Date: Tue, 09 Oct 2012 15:21:41 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> <20121008113932.GB16332@stefanha-thinkpad.redhat.com> <5072CE54.8020208@redhat.com> <20121009090811.GB13775@stefanha-thinkpad.redhat.com> <5073EDB3.3020804@redhat.com> <5073FE3A.1090903@redhat.com> <507401D8.8090203@redhat.com> <507405B5.4060108@redhat.com> <507410BD.6050901@redhat.com> <50741218.90000@redhat.com> <5074171A.2030904@redhat.com> <5074226A.3030907@redhat.com> In-Reply-To: <5074226A.3030907@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , Ping Fan Liu , Stefan Hajnoczi , qemu-devel@nongnu.org, Jan Kiszka On 10/09/2012 03:11 PM, Paolo Bonzini wrote: >> But no, it's actually impossible. Hotplug may be triggered from a vcpu >> thread, which clearly it can't be stopped. > > Hotplug should always be asynchronous (because that's how hardware > works), so it should always be possible to delegate the actual work to a > non-VCPU thread. Or not? The actual device deletion can happen from a different thread, as long as you isolate the device before. That's part of the garbage collector idea. vcpu thread: rcu_read_lock lookup dispatch mmio handler isolate queue(delete_work) rcu_read_unlock worker thread: process queue delete_work synchronize_rcu() / stop_machine() acquire qemu lock delete object drop qemu lock Compared to the garbage collector idea, this drops fined-grained locking for the qdev tree, a significant advantage. But it still suffers from dispatching inside the rcu critical section, which is something we want to avoid. I think refcounting is still the best direction, but maybe we can think of a new idea here. -- error compiling committee.c: too many arguments to function