Re: [Qemu-devel] Register uhci_reset() callback.

[Blue Swirl <blauwirbel@gmail.com>]

On 6/16/09, Jamie Lokier <jamie@shareable.org> wrote:
> Jamie Lokier wrote:
>
> > Blue Swirl wrote:
>  > It's analogous to a distributed atomic transaction problem.

I did not wrote this, it was you.

>  >
>  > So you need two phases:
>  >
>  >     - Restoring: All devices states are restored, one by one including
>  >       output levels of interrupt lines and GPIOs, but nothing actually
>  >       _happens_ when those levels are set.
>  >
>  >     - Running: All devices start running at the same instant from
>  >       their restored state.  They don't need to reexamine input
>  >       levels, because their internal states are already consistent
>  >       with the input levels.
>  >
>  > In the restoring phase, you might still use the normal functions to
>  > set output levels, but they would be prevented from being passed as
>  > changes to other devices.
>  >
>  > Anything else might be made to work with particular PICs etc., but
>  > two-phase restore is what you need to work with any wiring (including
>  > cycles) of arbitrary devices with arbitrary states.
>
>
> I should say, the above applies to both restoring saved state, and
>  whole system resets.
>
>  That's why real hardware has a nice long reset pulse, during which
>  every input change is ignored until the reset pulse is removed.

qemu_irq does not have state. It's different from real HW IRQ, so QEMU
devices don't need to do anything. I also had this confused earlier.