Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset

[Avi Kivity]

----- Original Message -----
> On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity <address@hidden> 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.  After the end of phase 1, everything is
> > settled.  During 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, outputs 
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 devices 
having different propagation delays.

At the end of phase 1, everything is settled.  This corresponds to T = 
max(reset latency of all devices).

Phase 2 is qemu_irq_lower() on all RESET inputs.  At this time, inputs begin 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.