qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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: Tue, 15 Apr 2025 21:31:03 -0300	[thread overview]
Message-ID: <87ecxteym0.fsf@suse.de> (raw)
In-Reply-To: <20250411114534.3370816-1-ppandit@redhat.com>

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.



  parent reply	other threads:[~2025-04-16  0:32 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 ` Fabiano Rosas [this message]
2025-04-16 12:59   ` [PATCH v9 0/7] Allow to enable multifd and postcopy migration together Fabiano Rosas
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=87ecxteym0.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).