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

[Blue Swirl]

On Sun, Oct 2, 2011 at 7:52 PM, Avi Kivity <address@hidden> wrote:
>
>
> ----- Original Message -----
>> On Sun, Oct 2, 2011 at 7:44 PM, Avi Kivity <address@hidden> wrote:
>> >> >
>> >> > A real device also ignores inputs during reset (or if it
>> >> > doesn't,
>> >> > we can just emulate that).
>> >>
>> >> Maybe this could work:
>> >> 1 - issue start of reset cycle (raise qemu_irq, unrealize):
>> >> internal
>> >> states reset, no I/O.
>> >> 2 - issue start of I/O, reset held (new phase): evaluate inputs
>> >> and
>> >> post outputs, but consider also that reset is still active, so
>> >> transition is not complete for all devices
>> >
>> > This doesn't correspond to real hardware.   Each device detects the
>> > reset edge independently.  There is no signal that says "all
>> > devices have seen the edge".
>>
>> Reset is not edge triggered but level signal.
>
> 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.

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.