On Tue, Sep 12, 2023 at 07:49:37PM -0300, Fabiano Rosas wrote:
> I figured what is going on here (test #1). At postcopy_pause_incoming()
> the state transition is ACTIVE -> PAUSED, but when the first recovery
> fails on the incoming side, the transition would have to be RECOVER ->
> PAUSED.
>
>
Peter Xu writes:
>> Scenario 1:
>> /x86_64/migration/postcopy/recovery/fail-twice
>>
>> the stacks are:
>>
>> Thread 8 (Thread 0x7fffd5ffe700 (LWP 30282) "live_migration"):
>> qemu_sem_wait
>> ram_dirty_bitmap_sync_all
>> ram_resume_prepare
>> qemu_savevm_state_resume_prepare
>>
On Tue, Sep 12, 2023 at 04:05:27PM -0400, Peter Xu wrote:
> Thanks for contributing the test case!
>
> Do you want me to pick this patch up (with modifications) and repost
> together with this series? It'll also work if you want to send a separate
> test patch. Let me know!
It turns out I
On Mon, Sep 11, 2023 at 09:31:51PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> Hi, sorry it took me so long to get to this.
Not a problem.
>
> > Normally the postcopy recover phase should only exist for a super short
> > period, that's the duration when QEMU is trying to recover from
Peter Xu writes:
Hi, sorry it took me so long to get to this.
> Normally the postcopy recover phase should only exist for a super short
> period, that's the duration when QEMU is trying to recover from an
> interrupted postcopy migration, during which handshake will be carried out
> for
Normally the postcopy recover phase should only exist for a super short
period, that's the duration when QEMU is trying to recover from an
interrupted postcopy migration, during which handshake will be carried out
for continuing the procedure with state changes from PAUSED -> RECOVER ->
