On Sat, Oct 1, 2011 at 6:47 AM, Jan Kiszka <jan.kis...@web.de> wrote: > On 2011-09-30 22:47, Blue Swirl wrote: >> That part of the discussion is obsolete (or at least uninteresting >> here). For example this message has a relevant example: >> http://lists.nongnu.org/archive/html/qemu-devel/2009-06/msg01081.html >> >> It's about VM restore, but the situation is similar during reset. > > Actually, that is not comparable as we are entering the device's > quiescent state.
It is. Here's an example for the reset case based on the Paul's original one. Because devices are reset in unpredictable order that they should not be communicating with other devices (e.g. by modifying IRQ lines). Consider a system with a device (DEV) and a level triggered interrupt controller (PIC1) with the ability to toggle the level where triggering happens, chained to a rising edge triggered interrupt controller (PIC2). (DEV) -> (PIC1) -> (PIC2) Before reset, DEV output is high, PIC1 has the interrupt unmasked (but high) and the trigger level is configured as active low, PIC2 has no pending interrupts. We now reset, so the state should be that DEV output is low, PIC1 has masked all interrupts and its input set to active high, and PIC2 has no pending interrupts. Devices are reset in the order PIC2, DEV, PIC1. If devices toggle their interrupts on reset then we get incorrect state after the reset: PIC2 is reset to the desired no-interrupts-pending state. DEV is reset. This lowers the IRQ, which is passed to PIC1. PIC1 still has the old interrupt mask and level set to active low, so it passes the IRQ through to PIC2, which detects the edge event and marks the interrupt as pending. PIC1 is reset, updates the new mask, sets the input level to active high and lowers its output. However this event does not clear the internal PIC2 pending interrupt flag, so machine state will be wrong after reset. Therefore it is incorrect to perform any qemu_irq activities during reset (also VM restore like the original example), don't you agree? 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. 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. >>> My series does not depend on this cleanup/fix, but the reason not to >>> apply remains wrong IMHO. >> >> Sorry, but if a patch is incorrect, it is not a cleanup nor a fix. > > Well, both current MIPS and PREP look like they would benefit from it. How?