[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Register uhci_reset() callback.
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] Register uhci_reset() callback. |
Date: |
Tue, 16 Jun 2009 21:10:01 +0300 |
On 6/16/09, Paul Brook <address@hidden> wrote:
> > > Devices should not cause IRQ state changes on restore. Commit 3dcd219f
> > > is incorrect.
> >
> > I'm not so sure about this, but I can't think of a restore sequence
> > where the IRQ state would need to be changed if the IRQs tied together
> > are handled correctly. But surely if the devices states are restored
> > in strange order, the state changes could cause problems because the
> > device receiving the IRQ may still contain old state.
>
>
> It's precisely because devices are restored 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) chained to an edge triggered interrupt controller (PIC2).
>
> (DEV) -> (PIC1) -> (PIC2)
>
> Before restore, DEV output is low, PIC1 has the interrupt unmasked (but low),
> PIC2 has no pending interrupts.
>
> We now restore a state where DEV output is high, PIC1 has masked the
> interrupt, and PIC2 has no pending interrupts. Devices are restored in he
> order PIC2, DEV, PIC1.
>
> If devices toggle their interrupts on restore then we get incorrect state
> after the restore:
>
> PIC2 is restored to the desired no-interrupts-pending state.
> DEV is restored. This raises the IRQ, which is passed to PIC1. PIC1 still has
> the old interrupt mask, so passes through to PIC2, which detects the edge
> event and marks the interrupt as pending.
> PIC1 is restored, updates the new mask and lowers its output. However this
> does not clear the internal PIC2 pending interrupt flag, so machine state
> will
> be wrong after resume.
Yes, this is the "bad" restore scenario that I had in mind. I still
have a nagging feeling that there is a reverse scenario, where in
order to reach good state, you would have to call the IRQ function.
Anyway, 3dcd219f may not be correct in that case either.
- Re: [Qemu-devel] Register uhci_reset() callback., (continued)
- Re: [Qemu-devel] Register uhci_reset() callback., Blue Swirl, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Gleb Natapov, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Blue Swirl, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Gleb Natapov, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Blue Swirl, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Gleb Natapov, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Avi Kivity, 2009/06/18
- Re: [Qemu-devel] Register uhci_reset() callback., Paul Brook, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Blue Swirl, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Paul Brook, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback.,
Blue Swirl <=
- Re: [Qemu-devel] Register uhci_reset() callback., Jamie Lokier, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Jamie Lokier, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Blue Swirl, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Gleb Natapov, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Paul Brook, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Gleb Natapov, 2009/06/16
- Re: [Qemu-devel] Register uhci_reset() callback., Paul Brook, 2009/06/16