On 2011-08-30 21:19, Blue Swirl wrote: > On Mon, Aug 29, 2011 at 9:13 PM, Avi Kivity 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