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

[Blue Swirl]

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?

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?