Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Blue Swirl]

On Mon, Sep 5, 2011 at 8:38 AM, Edgar E. Iglesias
<address@hidden> 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<address@hidden>  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.