Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset

[Blue Swirl]

On Sun, Oct 2, 2011 at 4:27 PM, Jan Kiszka <address@hidden> wrote:
> On 2011-10-01 09:31, Blue Swirl wrote:
>> On Sat, Oct 1, 2011 at 6:47 AM, Jan Kiszka <address@hidden> 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.