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

[Blue Swirl]

On Sun, Oct 2, 2011 at 8:39 PM, Avi Kivity <address@hidden> wrote:
>
>
> ----- 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.

With this definition of phases, at least the DEV/PIC1/PIC2 example I
presented earlier isn't possible. PIC2 would ignore the new input, so
it would retain reset state.