On Sun, Oct 2, 2011 at 8:17 PM, Avi Kivity <a...@redhat.com> wrote: >> > >> > It doesn't help. There is propagation delay there as well. If the >> > input wins the race against reset, the launch sequence is started. >> >> To bring the example back to QEMU, a disk write could be issued or >> network packet could be sent. But still, this only confirms that >> during the initial phase of reset, no output activities can be >> allowed >> to avoid such problems. > > In fact these aren't problems. The packet may be sent or data written, as > long as they aren't corrupted. A device is allowed to "delay" a reset (but > not indefinitely).
Oh, but corruption could easily happen. Consider for example a disk controller waiting for DMA ready signal a device separate from the DMA controller. Due to reset glitches in the device or signal chain, the DMA ready signal arrives but the DMA controller still contains old information, writing the data to disk from wrong memory location. >> > Okay. I still don't think there is a problem. >> >> There is, Jan's real example and my theoretical cases show that. >> > > I believe your example has the same problem on real hardware. Jan, is your > problem not solved by two-phase reset? On real hardware the problem is masked by the long reset pulse. We have an infinitely short pulse. Jan's case should be OK, a CPU doesn't have any outputs.
