From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RARTo-0006NP-00 for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:13:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RARTm-0007Lc-LG for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:13:39 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:40419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RARTm-0007LM-Gx for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:13:38 -0400 Received: by qadb10 with SMTP id b10so1648659qad.4 for ; Sun, 02 Oct 2011 12:13:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E8897BA.2060400@redhat.com> References: <4E838F0B.2010900@web.de> <4E856600.9010703@web.de> <4E86B793.5090003@web.de> <4E8897BA.2060400@redhat.com> From: Blue Swirl Date: Sun, 2 Oct 2011 19:13:18 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Jan Kiszka , qemu-devel On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity wrote: > On 10/01/2011 10:31 AM, Blue Swirl wrote: >> >> Therefore it is incorrect to perform any qemu_irq activities during >> reset (also VM restore like the original example), don't you agree? > > It is not incorrect. =C2=A0Real hardware updates outputs on RESET asserti= on, and > real hardware deals with devices entering reset at different times (due t= o > signal propagation delay or slow devices). Yes, but on real hardware, during the propagation of any effects, the reset line is held asserted for millions of clock cycles in order to stabilize the machine. >> If we continued to reset all the devices (call the reset handlers >> multiple times), eventually machine state should stabilize (equivalent >> of real HW with nice long reset pulses), but on QEMU the reset event >> is infinitely short so we have to be more careful. > > calling qemu_irq_pulse(reset) simulates a reset signal of any length (sin= ce > nothing happens between the two edges). Not really. The first edge could trigger the reset (but don't sample inputs) phase, this would be equal to forcefully stabilizing any device internal state. The second would release the device inputs, but that's also a source of problems. >> Actually I don't think that even a two-phase reset with qemu_irq or >> Pin activity on the second phase would produce correct results in >> every obscure case. Though this may be detectable since the start >> state would be known. > > The output signals have to stabilize before the second edge of the reset > signal. They can't since the devices' inputs are ignored at that phase.