On Sun, Oct 2, 2011 at 4:27 PM, Jan Kiszka <jan.kis...@web.de> wrote: > On 2011-10-01 09:31, Blue Swirl wrote: >> 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? > > A rather odd but valid counterexample. Have you seen such a setup already? > > But I'll provide a real example where the model "no IRQ change > propagated on reset, devices handle this internally" fails as well: > > PIC -> CPU > > We have a level-triggered active-high line in this case. When the CPU is > reset, it "somehow" knows that it is attached to the PIC and assumes > that this device is reset as well. Therefore, the CPU clears its cached > input state on reset. That works if both devices are actually reset. But > it fails if only the CPU is reset while the PIC output is active.
OK, we have a positive incorrect case and negative one. This means that the current model is broken. > That's likely the reason why MIPS and PPC/PREP do no touch the cached > interrupt line state on reset but expect that the source will inform > them whenever the line goes down - e.g. due to reset. > > The conflict we are in with the current reset model is hard-coding the > board wiring and source knowledge into sink device models vs. > propagating reset states. I agree that both have their corner cases. > > But in order to continue with properly disentangling board knowledge > from generic device models, we should head for the latter variant where > already possible (like in the i8259 case). On the long term, this should > be resolved using a two-stage model where every root of an interrupt > line signals its state down the chain at the end of a reset phase. I don't think that even a two phase reset can solve the instability in all possible cases. If the qemu_irq lines form a complex network, several cycles could be needed until the effects have propagated and the network has stabilized. In a defective network (loop with NOT in the middle), the network could oscillate forever and never stabilize (or until qemu_irq callbacks fill the stack and QEMU crashes), just like real HW.
