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

[Blue Swirl]

On Tue, Aug 30, 2011 at 7:28 PM, Jan Kiszka <address@hidden> wrote:
> On 2011-08-30 21:19, Blue Swirl wrote:
>> On Mon, Aug 29, 2011 at 9:13 PM, Avi Kivity <address@hidden> wrote:
>>> On 08/30/2011 12:06 AM, Jan Kiszka wrote:
>>>>
>>>>>
>>>>>  Does this need to be save/restored for migration?
>>>>
>>>> Nope, but we need some other measure. I thought to remember the pic was
>>>> refreshing this after load, but I do not find any traces of this now. We
>>>> likely need a post_load handler in the i8259 that re-asserts the IRQ as
>>>> required.
>>>>
>>>
>>> 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.
>
> Yes, that's the current state. Once we have bidirectional IRQ links in
> place (pushing downward, querying upward - required to skip IRQ routers
> for fast, lockless deliveries), that should change again.

I don't think it should change. If stateful or dynamically routing
IRQs were implemented, then those IRQs should also save and restore
their state, so again the devices would not need to do anything.

> For now, that's what I realized in the meantime as well, we can't help
> saving pic_level in the APIC state.
>
> What is the state of substates in pre-1.0? Do we try to use those again
> in favor of simple field additions under a new state version?
>
> Jan
>
>