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

[Blue Swirl]

On Sun, Oct 2, 2011 at 8:03 PM, Avi Kivity <address@hidden> wrote:
>> >
>> > It still has propagation delay.  If your XNOR gate connects to the
>> > NORAD master launch controller, your design may have side effects.
>>
>> Hopefully the reset signal would control also the edge triggered
>> launch controller.
>
> It doesn't help.  There is propagation delay there as well.  If the input 
> wins the race against reset, the launch sequence is started.

To bring the example back to QEMU, a disk write could be issued or
network packet could be sent. But still, this only confirms that
during the initial phase of reset, no output activities can be allowed
to avoid such problems.

>> The delays are one reason why real reset pulses are so long. The
>> other
>> reasons are the stabilization effects, internal and external.
>>
>> >> > We should either have just 1, or merge 1 and 2.
>> >> >
>> >>
>> >> Then we'd be back to where the problems started.
>> >>
>> >
>> > Sorry, I don't see the problem yet.
>>
>> I'm not sure we have a complete solution either. Phase 1 would solve
>> most problems with old state which is the most important issue here.
>> If the machine refuses to wake up from reset, this should be noticed
>> quite soon, so we could move to dual phase system while still
>> searching for the best possible system in all possible worlds.
>>
>
>
> Okay.  I still don't think there is a problem.

There is, Jan's real example and my theoretical cases show that.