qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Wed, 31 Aug 2011 16:59:40 +0000

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]