From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RASor-0005Uh-CH for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:39:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RASoq-0003gm-Be for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:39:29 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:53001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RASoq-0003gb-0u for qemu-devel@nongnu.org; Sun, 02 Oct 2011 16:39:28 -0400 Date: Sun, 02 Oct 2011 16:39:25 -0400 (EDT) From: Avi Kivity Message-ID: <05381148-fd81-4eaa-a49f-98ce2f1e4a6f@zmail04.collab.prod.int.phx2.redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Blue Swirl Cc: Jan Kiszka , Anthony Liguori , qemu-devel ----- Original Message ----- > On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity wrote: > >> > > >> > What I'm saying is that RESET order isn't defined on real > >> > hardware > >> > either, due to signal propagation effects. > >> > >> Yes, but there the millions of reset cycles help immensely to > >> suppress > >> the effects. > >> > > > > That's modeled correctly. =C2=A0After the end of phase 1, everything is= > > settled. =C2=A0During phase 1, you can see some spikes, but you can see= > > them on real hardware as well. > > No. With two phase reset (like I understood it), at the beginning of > phase, everything internal is settled (registers reset), no I/O. > After > the phase 1, starting the external I/O activities cause spikes but > these are not suppressed. Phase 1 is qemu_irq_raise() on all RESET inputs. During this period, outpu= ts of devices that have seen the edge move to their RESET values, and they = ignore inputs. Because it doesn't happen simultaneously, some devices see = those outputs moving and may act on them. This corresponds to different de= vices having different propagation delays. At the end of phase 1, everything is settled. This corresponds to T =3D ma= x(reset latency of all devices). Phase 2 is qemu_irq_lower() on all RESET inputs. At this time, inputs begi= n to be considered. Between phase 1 and phase 2 are those millions of cycles (minus T above). So yes, you see spikes, but you also see them on real hardware.