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
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 behavior of the restored system wil
14 matches
Mail list logo
