From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLGMt-0002vA-6o for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:39:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLGMs-00081T-0P for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:39:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLGMr-00081D-MR for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:39:45 -0400 Message-ID: <507301A5.8030004@redhat.com> Date: Mon, 08 Oct 2012 18:39:01 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <506F1934.5000002@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] versatile: Push lsi initialization to the end List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , Jan Kiszka , Anthony Liguori , qemu-devel Il 08/10/2012 18:33, Peter Maydell ha scritto: > On 5 October 2012 18:30, Jan Kiszka wrote: >> This is nasty, but there is no better way given current mux logic: >> >> As setting up the block device will trigger a qemu_bh_poll while there >> are qemu_chr open events in the queue, we have to register the UARTs >> and everything else that might be mux'ed first so that the right active >> frontend is already registered when the bottom-half is finally >> processed. > > So I guess this comes down to what the semantics of bottom halves are. > I can see two plausible options: > > 1. bottom halves are a mechanism provided by our cpu/device > simulation framework, and so will never be run before the > simulation is fully initialised > * this means devices can register BHs which set irq lines, > send events to chr mux front ends etc etc > * it also means that device setup mustn't trigger a bh_poll > (so we'd need to track down the bit of the block device > setup that's causing this) > > 2. bottom halves are a generic mechanism that you can use > not just as part of the simulation, and so BHs may run > as soon as they're registered > * this would let us use them for arbitrary purposes in init > * we'd need to audit and fix all the current uses to check > whether they're safe to run early or if they need to have > a 'do nothing if simulation not running' check 3. bottom halves are an internal concept to the block layer that has been hijacked by device models. The bottom half idea is that the code would run as soon as the current code is done with this subsystem; ideally, you would instead queue a work item in a thread-pool and the code would block on the same fine-grained lock as the subsystem that created the bottom half. Work items from different subsystems would be able to run concurrently---of course that's not too helpful while we have a single lock for the whole iothread... Stefan's work should be able to kill qemu_bh_new inside the block layer (replacing it with aio_bh_new), so qemu_bh_new can be repurposed to something that doesn't conflict with the block layer. Paolo