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

[Blue Swirl]

On Sun, Oct 2, 2011 at 7:20 PM, Avi Kivity <address@hidden> wrote:
>
>
> ----- Original Message -----
>> On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity <address@hidden> wrote:
>> > On 10/01/2011 10:31 AM, Blue Swirl wrote:
>> >>
>> >> Therefore it is incorrect to perform any qemu_irq activities
>> >> during
>> >> reset (also VM restore like the original example), don't you
>> >> agree?
>> >
>> > It is not incorrect.  Real hardware updates outputs on RESET
>> > assertion, and
>> > real hardware deals with devices entering reset at different times
>> > (due to
>> > signal propagation delay or slow devices).
>>
>> Yes, but on real hardware, during the propagation of any effects, the
>> reset line is held asserted for millions of clock cycles in order to
>> stabilize the machine.
>
> But nothing can happen in these cycles, since qemu emulates everything that 
> happens in the on the edge, and any timers will be cancelled.

There are some wild activities in the beginning of the reset, but
after that nothing will happen.

>>
>> >> If we continued to reset all the devices (call the reset handlers
>> >> multiple times), eventually machine state should stabilize
>> >> (equivalent
>> >> of real HW with nice long reset pulses), but on QEMU the reset
>> >> event
>> >> is infinitely short so we have to be more careful.
>> >
>> > calling qemu_irq_pulse(reset) simulates a reset signal of any
>> > length (since
>> > nothing happens between the two edges).
>>
>> Not really. The first edge could trigger the reset (but don't sample
>> inputs) phase, this would be equal to forcefully stabilizing any
>> device internal state. The second would release the device inputs,
>> but
>> that's also a source of problems.
>
>
> Can you elaborate on the problems?
>
>>
>> >> Actually I don't think that even a two-phase reset with qemu_irq
>> >> or
>> >> Pin activity on the second phase would produce correct results in
>> >> every obscure case. Though this may be detectable since the start
>> >> state would be known.
>> >
>> > The output signals have to stabilize before the second edge of the
>> > reset
>> > signal.
>>
>> They can't since the devices' inputs are ignored at that phase.
>>
>
> 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
3 - release reset line (lower qemu_irq, realize): gentlemen, start your engines

During phase 2 some of the network effects could be contained.

> I would really like to see a concrete example we can discuss.

See my previous message.