On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity <a...@redhat.com> 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. >> 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. >> 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.
