From: Peter Xu <peterx@redhat.com>
To: Yuan Liu <yuan1.liu@intel.com>
Cc: farosas@suse.de, qemu-devel@nongnu.org, jason.zeng@intel.com,
yichen.wang@bytedance.com,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Subject: Re: [PATCH 0/3] bugfixes for migration using compression methods
Date: Wed, 18 Dec 2024 12:12:57 -0500 [thread overview]
Message-ID: <Z2MCmQ2YAMVb9kSy@x1n> (raw)
In-Reply-To: <20241218091413.140396-1-yuan1.liu@intel.com>
On Wed, Dec 18, 2024 at 05:14:10PM +0800, Yuan Liu wrote:
> This set of patches is used to fix the bugs of incorrect migration
> memory data when compression is enabled.
>
> The method to reproduce this bug is as follows
> 1. Run "stress-ng --class memory --all 1" in the source side, the
> stress-ng tool comes from https://github.com/ColinIanKing/stress-ng.git
>
> 2. Enable the multifd compression methods and start migration
> e.g. migrate_set_parameter multifd-compression qpl
>
> 3. The guest kernel will crash automatically or crash at shutdown after
> the migration is complete
>
> The root cause of the bugs and the solutions are described in detail in
> the patch.
>
> My verification method as follows
> 1. Start the VM and run the stess-ng test command on the source side.
> 2. Start the VM with "-S" parameter on the target side, it is
> used to pause the vCPUs after migration.
> 3. After the migration is successful, use the dump-guest-memory command
> to export the memory data of the source and target VMs respectively.
> 4. Use "cmp -l source_memory target_memory" to verify memory data.
This looks like a good idea to test memory intergrity. I wonder if we can
do that in some, or all, of our migration qtests.
I didn't check the latter 2 patches but I assume they can also have a
proper Fixes tag.
The other thing is uadk seems also broken from that regard.. we could add
one patch for it, but the testing may be challenging for any of us. In all
case, I copy Shameer.
--
Peter Xu
next prev parent reply other threads:[~2024-12-18 17:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 9:14 [PATCH 0/3] bugfixes for migration using compression methods Yuan Liu
2024-12-18 9:14 ` [PATCH 1/3] multifd: bugfix " Yuan Liu
2024-12-18 17:03 ` Peter Xu
2024-12-19 8:42 ` Liu, Yuan1
2024-12-18 9:14 ` [PATCH 2/3] multifd: bugfix for incorrect migration data with QPL compression Yuan Liu
2024-12-18 17:08 ` Peter Xu
2024-12-18 9:14 ` [PATCH 3/3] multifd: bugfix for incorrect migration data with qatzip compression Yuan Liu
2024-12-18 17:08 ` Peter Xu
2024-12-18 17:12 ` Peter Xu [this message]
2025-01-12 13:12 ` [PATCH 0/3] bugfixes for migration using compression methods Michael Tokarev
2025-01-13 0:58 ` Liu, Yuan1
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=Z2MCmQ2YAMVb9kSy@x1n \
--to=peterx@redhat.com \
--cc=farosas@suse.de \
--cc=jason.zeng@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yichen.wang@bytedance.com \
--cc=yuan1.liu@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.