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