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

[Avi Kivity]

----- 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.


>
> >> 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).


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