On Mon, Sep 5, 2011 at 8:38 AM, Edgar E. Iglesias <edgar.igles...@gmail.com> wrote: > On Sat, Sep 03, 2011 at 02:53:31PM -0500, Anthony Liguori wrote: >> On 08/31/2011 11:59 AM, Blue Swirl wrote: >> > On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity<a...@redhat.com> wrote: >> >> On 08/30/2011 10:19 PM, Blue Swirl wrote: >> >>> >> >>>> >> >>>> We need some kind of two phase restore. In the first phase all state >> >>>> is >> >>>> restored; since some of that state drivers outputs that are input to >> >>>> other >> >>>> devices, they may experience an edge, and we need to supress that. In >> >>>> the >> >>>> second phase edge detection is unsupressed and the device goes live. >> >>> >> >>> No. Devices may not perform any externally visible activities (like >> >>> toggle a qemu_irq) during or after load because 1) qemu_irq is >> >>> stateless and 2) since the receiving end is also freshly loaded, both >> >>> states are already in synch without any calls or toggling. >> >> >> >> That makes it impossible to migrate level-triggered irq lines. Or at >> >> least, >> >> the receiver has to remember the state, instead of (or in addition to) the >> >> sender. >> > >> > Both ends probably need to remember the state. That should work >> > without any multiphase restores and transient suppressors. >> > >> > It might be also possible to introduce stateful signal lines which >> > save and restore their state, then the receiving end could check what >> > is the current level. However, if you consider that the devices may be >> > restored in random order, if the IRQ line device happens to be >> > restored later, the receiver would still get wrong information. Adding >> > priorities could solve this, but I think stateless IRQs are the only >> > sane way. >> >> We shouldn't really use the term IRQ as it's confusing. I like the term >> "pin" better because that describes what we're really talking about. >> >> qemu_irq is designed oddly today because is represents something that is >> intrinsically state (whether a pin is high or low) with an edge >> notification with the assumption that the state is held somewhere else >> (which is usually true). > > I don't agree. That's not what qemu_irq represents. > It represents a wire, a mechanism to drive changes through logic paths > between state. It is intrinsically stateless. > > It may be the case that it is missused in some places, or that it isn't > always the best thing to use to represent what ever you need to represent, > so that you want to complement with other mechanisms. > But universally replacing it with a stateful alternative seems wrong to me.
Maybe there could be a stateless version of Pin for optimization: Line? This would probably save one bool worth of memory and one memory store access for each IRQ event.
