On Wed, Sep 10, 2014 at 11:58:34AM +0200, Paolo Bonzini wrote: > Il 10/09/2014 12:50, Michael S. Tsirkin ha scritto: > > OK, got this, thanks for the explanation! > > So the reason i8259 might be out of sync is > > because it's not yet deserialized. > > Yes, especially the IMR/IRR/ISR fields. > > > I think it's a good idea to put (at least the > > last part) in the commit log. > > Like this: > > This patch disables raising an irq while loading the state of PCI bridge. > Because the i8259 has not been deserialized yet, raising an interrupt > could bring the system out-of-sync with the migration source. For > example, > the migration source could have masked the interrupt in the i8259. On the > destination, the i8259 device model would not know that yet and would > trigger an interrupt in the CPU. > > This patch eliminates raising an irq and just restores the calculated > state fields in post_load function. Interrupt state will be deserialized > separately through the IRR field of the i8259.
Yes, thanks! Except imho it's a bit better to s/raising/setting/ in the last paragraph. > > Also it's updating irq state, not just raising irq, > > that might be problematic, right? > > Well, the i8259 is in the reset state so ISR=IRR=0, aka all IRQ lines > are known to be low. By luck, yes. > But yes, in general it's the update that is > problematic.
