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

[Jan Kiszka]

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.

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.

Jan

signature.asc
Description: OpenPGP digital signature