On Wed, Sep 10, 2014 at 12:07:22PM +0200, Paolo Bonzini wrote:
> Il 10/09/2014 13:04, Michael S. Tsirkin ha scritto:
> >> > This patch disables raising an irq while loading the state of PCI
> >> > bridge.
> >> > Because the i8259 has not been deserialized yet, raising an interrupt
> >> >
Il 10/09/2014 13:04, Michael S. Tsirkin ha scritto:
>> > 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
>>
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.
>
>
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
On Wed, Sep 10, 2014 at 10:38:46AM +0200, Paolo Bonzini wrote:
> Il 09/09/2014 22:51, Michael S. Tsirkin ha scritto:
> > > i440FX/PIIX3 state is loaded before i8259, so the interrupt will never
> > > be in the i8259 ISR. I am not sure why it is a problem for
> > > record/replay, but I think it's p
On Wed, Sep 10, 2014 at 11:05:39AM +0200, Paolo Bonzini wrote:
> Il 10/09/2014 10:51, Peter Maydell ha scritto:
> > > What is not okay (and I think it should be a rule) is to touch other
> > > devices from post_load, unless you know that they are deserialized
> > > first. For example it's okay for
Il 10/09/2014 10:51, Peter Maydell ha scritto:
> > What is not okay (and I think it should be a rule) is to touch other
> > devices from post_load, unless you know that they are deserialized
> > first. For example it's okay for a PCI device to talk to the parent
> > bridge in its post_load functio
On 10 September 2014 09:38, Paolo Bonzini wrote:
> Il 09/09/2014 22:51, Michael S. Tsirkin ha scritto:
>> Sorry I still don't understand. Why do stuff from vmstate callback then?
>> How is it different?
>
> Reconstructing internal state from post_load is okay.
>
> What is not okay (and I think it
Il 09/09/2014 22:51, Michael S. Tsirkin ha scritto:
> > i440FX/PIIX3 state is loaded before i8259, so the interrupt will never
> > be in the i8259 ISR. I am not sure why it is a problem for
> > record/replay, but I think it's plausible to consider this a bug. i8259
> > state should not be affecte
On Tue, Sep 09, 2014 at 07:16:19PM +0200, Paolo Bonzini wrote:
> Il 09/09/2014 15:54, Michael S. Tsirkin ha scritto:
> >
> > Hmm I don't understand.
> > You are removing call to piix3_update_irq_levels
> > this call is supposed to just sync up bus to
> > irq level.
> >
> > How can this change sys
Il 09/09/2014 15:54, Michael S. Tsirkin ha scritto:
>
> Hmm I don't understand.
> You are removing call to piix3_update_irq_levels
> this call is supposed to just sync up bus to
> irq level.
>
> How can this change system state? Saved state
> is supposed to already be in sync.
i440FX/PIIX3 state
On Tue, Sep 09, 2014 at 02:30:08PM +0200, Paolo Bonzini wrote:
> From: Pavel Dovgalyuk
>
> This patch disables raising an irq while loading the state of PCI bridge.
> The aim of this patch is preserving the same behavior while saving and
> restoring the VM state. IRQ is not raised while saving th
Paolo Bonzini wrote:
> From: Pavel Dovgalyuk
>
> This patch disables raising an irq while loading the state of PCI bridge.
> The aim of this patch is preserving the same behavior while saving and
> restoring the VM state. IRQ is not raised while saving the state of the
> bridge.
> That's why the
13 matches
Mail list logo
