From: Fabiano Rosas <farosas@suse.de>
To: Prasad Pandit <ppandit@redhat.com>, qemu-devel@nongnu.org
Cc: peterx@redhat.com, berrange@redhat.com,
Prasad Pandit <pjp@fedoraproject.org>
Subject: Re: [PATCH v9 0/7] Allow to enable multifd and postcopy migration together
Date: Wed, 16 Apr 2025 09:59:39 -0300 [thread overview]
Message-ID: <87bjswfeis.fsf@suse.de> (raw)
In-Reply-To: <87ecxteym0.fsf@suse.de>
Fabiano Rosas <farosas@suse.de> writes:
> Prasad Pandit <ppandit@redhat.com> writes:
>
>> From: Prasad Pandit <pjp@fedoraproject.org>
>>
>> Hello,
>>
>>
>> * This series (v9) does minor refactoring and reordering changes as
>> suggested in the review of earlier series (v8). Also tried to
>> reproduce/debug a qtest hang issue, but it could not be reproduced.
>> From the shared stack traces it looked like Postcopy thread was
>> preparing to finish before migrating all the pages.
>
> The issue is that a zero page is being migrated by multifd but there's
> an optimization in place that skips faulting the page in on the
> destination. Later during postcopy when the page is found to be missing,
> postcopy (@migrate_send_rp_req_pages) believes the page is already
> present due to the receivedmap for that pfn being set and thus the code
> accessing the guest memory just sits there waiting for the page.
>
> It seems your series has a logical conflict with this work that was done
> a while back:
>
> https://lore.kernel.org/all/20240401154110.2028453-1-yuan1.liu@intel.com/
>
> The usage of receivedmap for multifd was supposed to be mutually
> exclusive with postcopy. Take a look at the description of that series
> and at postcopy_place_page_zero(). We need to figure out what needs to
> change and how to do that compatibly. It might just be the case of
> memsetting the zero page always for postcopy, but I havent't thought too
> much about it.
>
> There's also other issues with the series:
>
> https://gitlab.com/farosas/qemu/-/pipelines/1770488059
>
> The CI workers don't support userfaultfd so the tests need to check for
> that properly. We have MigrationTestEnv::has_uffd for that.
>
> Lastly, I have seem some weirdness with TLS channels disconnections
> leading to asserts in qio_channel_shutdown() in my testing. I'll get a
> better look at those tomorrow.
Ok, you can ignore this last paragraph. I was seeing the postcopy
recovery test disconnect messages, those are benign.
next prev parent reply other threads:[~2025-04-16 13:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 11:45 [PATCH v9 0/7] Allow to enable multifd and postcopy migration together Prasad Pandit
2025-04-11 11:45 ` [PATCH v9 1/7] migration/multifd: move macros to multifd header Prasad Pandit
2025-04-11 11:45 ` [PATCH v9 2/7] migration: refactor channel discovery mechanism Prasad Pandit
2025-04-17 16:07 ` Fabiano Rosas
2025-04-11 11:45 ` [PATCH v9 3/7] migration: Add save_postcopy_prepare() savevm handler Prasad Pandit
2025-04-17 16:07 ` Fabiano Rosas
2025-04-11 11:45 ` [PATCH v9 4/7] migration/ram: Implement save_postcopy_prepare() Prasad Pandit
2025-04-17 16:08 ` Fabiano Rosas
2025-04-11 11:45 ` [PATCH v9 5/7] migration: enable multifd and postcopy together Prasad Pandit
2025-04-11 11:45 ` [PATCH v9 6/7] tests/qtest/migration: consolidate set capabilities Prasad Pandit
2025-04-17 16:11 ` Fabiano Rosas
2025-04-11 11:45 ` [PATCH v9 7/7] tests/qtest/migration: add postcopy tests with multifd Prasad Pandit
2025-04-17 16:10 ` Fabiano Rosas
2025-04-16 0:31 ` [PATCH v9 0/7] Allow to enable multifd and postcopy migration together Fabiano Rosas
2025-04-16 12:59 ` Fabiano Rosas [this message]
2025-04-17 11:13 ` Prasad Pandit
2025-04-17 16:05 ` Fabiano Rosas
2025-04-23 22:50 ` Peter Xu
2025-04-29 12:51 ` Prasad Pandit
2025-04-29 13:04 ` Peter Xu
2025-04-29 13:28 ` Prasad Pandit
2025-04-29 13:47 ` Peter Xu
2025-04-29 15:20 ` Prasad Pandit
2025-04-29 15:49 ` Peter Xu
2025-05-05 19:01 ` Fabiano Rosas
2025-05-06 12:32 ` Prasad Pandit
2025-05-05 19:04 ` Fabiano Rosas
2025-05-06 12:38 ` Prasad Pandit
2025-05-06 13:40 ` Fabiano Rosas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bjswfeis.fsf@suse.de \
--to=farosas@suse.de \
--cc=berrange@redhat.com \
--cc=peterx@redhat.com \
--cc=pjp@fedoraproject.org \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).