From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGe3m-00075x-6b for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:11:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGe3h-0006wS-9M for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:11:05 -0400 Received: from [199.232.76.173] (port=33343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGe3g-0006vs-Ls for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:11:00 -0400 Received: from mail-fx0-f209.google.com ([209.85.220.209]:43507) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGe3g-0007TP-BU for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:11:00 -0400 Received: by fxm5 with SMTP id 5so1583590fxm.34 for ; Tue, 16 Jun 2009 12:10:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090616190529.GO11893@shareable.org> References: <20090611084808.GA19508@redhat.com> <200906161754.59643.paul@codesourcery.com> <200906161900.11811.paul@codesourcery.com> <20090616185218.GK11893@shareable.org> <20090616190529.GO11893@shareable.org> Date: Tue, 16 Jun 2009 22:10:59 +0300 Message-ID: Subject: Re: [Qemu-devel] Register uhci_reset() callback. From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Avi Kivity , Gleb Natapov , Paul Brook On 6/16/09, Jamie Lokier wrote: > Jamie Lokier wrote: > > > Blue Swirl wrote: > > It's analogous to a distributed atomic transaction problem. I did not wrote this, it was you. > > > > So you need two phases: > > > > - Restoring: All devices states are restored, one by one including > > output levels of interrupt lines and GPIOs, but nothing actually > > _happens_ when those levels are set. > > > > - Running: All devices start running at the same instant from > > their restored state. They don't need to reexamine input > > levels, because their internal states are already consistent > > with the input levels. > > > > In the restoring phase, you might still use the normal functions to > > set output levels, but they would be prevented from being passed as > > changes to other devices. > > > > Anything else might be made to work with particular PICs etc., but > > two-phase restore is what you need to work with any wiring (including > > cycles) of arbitrary devices with arbitrary states. > > > I should say, the above applies to both restoring saved state, and > whole system resets. > > That's why real hardware has a nice long reset pulse, during which > every input change is ignored until the reset pulse is removed. qemu_irq does not have state. It's different from real HW IRQ, so QEMU devices don't need to do anything. I also had this confused earlier.