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

[Jan Kiszka]

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.

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

signature.asc
Description: OpenPGP digital signature