From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGd6m-0005ku-CQ for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:10:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGd6i-0005dx-EV for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:10:07 -0400 Received: from [199.232.76.173] (port=56340 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGd6h-0005dp-Ja for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:10:03 -0400 Received: from mail-fx0-f209.google.com ([209.85.220.209]:40239) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGd6h-0005AN-85 for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:10:03 -0400 Received: by fxm5 with SMTP id 5so1546388fxm.34 for ; Tue, 16 Jun 2009 11:10:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <200906161900.11811.paul@codesourcery.com> References: <20090611084808.GA19508@redhat.com> <200906161754.59643.paul@codesourcery.com> <200906161900.11811.paul@codesourcery.com> Date: Tue, 16 Jun 2009 21:10:01 +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: Paul Brook Cc: qemu-devel@nongnu.org, Gleb Natapov , Avi Kivity On 6/16/09, Paul Brook wrote: > > > Devices should not cause IRQ state changes on restore. Commit 3dcd219f > > > is incorrect. > > > > I'm not so sure about this, but I can't think of a restore sequence > > where the IRQ state would need to be changed if the IRQs tied together > > are handled correctly. But surely if the devices states are restored > > in strange order, the state changes could cause problems because the > > device receiving the IRQ may still contain old state. > > > It's precisely because devices are restored in unpredictable order that they > should not be communicating with other devices (e.g. by modifying IRQ lines). > > Consider a system with a device (DEV) and a level triggered interrupt > controller (PIC1) chained to an edge triggered interrupt controller (PIC2). > > (DEV) -> (PIC1) -> (PIC2) > > Before restore, DEV output is low, PIC1 has the interrupt unmasked (but low), > PIC2 has no pending interrupts. > > We now restore a state where DEV output is high, PIC1 has masked the > interrupt, and PIC2 has no pending interrupts. Devices are restored in he > order PIC2, DEV, PIC1. > > If devices toggle their interrupts on restore then we get incorrect state > after the restore: > > PIC2 is restored to the desired no-interrupts-pending state. > DEV is restored. This raises the IRQ, which is passed to PIC1. PIC1 still has > the old interrupt mask, so passes through to PIC2, which detects the edge > event and marks the interrupt as pending. > PIC1 is restored, updates the new mask and lowers its output. However this > does not clear the internal PIC2 pending interrupt flag, so machine state will > be wrong after resume. Yes, this is the "bad" restore scenario that I had in mind. I still have a nagging feeling that there is a reverse scenario, where in order to reach good state, you would have to call the IRQ function. Anyway, 3dcd219f may not be correct in that case either.