From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T64AD-0006lL-B8 for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:35:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T64AA-0000Z8-LS for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:35:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T64AA-0000Z2-Bn for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:35:50 -0400 Message-ID: <503BBDFC.8070806@redhat.com> Date: Mon, 27 Aug 2012 11:35:40 -0700 From: Avi Kivity MIME-Version: 1.0 References: <1345801763-24227-1-git-send-email-qemulist@gmail.com> <1345801763-24227-11-git-send-email-qemulist@gmail.com> <874nnoh3pg.fsf@codemonkey.ws> <503B8C1E.6090800@siemens.com> <87pq6cfjtm.fsf@codemonkey.ws> <503B91A9.7010507@siemens.com> <87k3wkjobd.fsf@codemonkey.ws> In-Reply-To: <87k3wkjobd.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Liu Ping Fan , Paolo Bonzini , Liu Ping Fan , "qemu-devel@nongnu.org" On 08/27/2012 09:24 AM, Anthony Liguori wrote: > > > > I'm sure we should leave existing code alone wherever possible, focusing > > on providing alternative versions for those paths that matter. Example: > > Most timers are fine under BQL. But some sensitive devices (RTC or HPET > > as clock source) will want their own timers. So the approach is to > > instantiate a separate, also prioritizeable instance of the timer > > subsystem for them and be done. > > I disagree. I think we conver the timer subsystem to be lockless and > then let some devices acquire the BQL during dispatch. I agree with your disagreement but disagree with the rest. The timer subsystem should have its own internal locking that callers will not be aware of. Requiring devices to acquire the bql will lead to deadlocks. Note that fine-grained locking timers will also require reference counting: you want to call the timer expiration callback after releasing the timer subsystem lock, so you need to make sure the callback does not go away. Linux manages without it (hrtimer_interrupt), so maybe we can too. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.