From: Peter Xu <peterx@redhat.com>
To: Hao Xiang <hao.xiang@bytedance.com>
Cc: Fabiano Rosas <farosas@suse.de>,
pbonzini@redhat.com, berrange@redhat.com, eduardo@habkost.net,
eblake@redhat.com, armbru@redhat.com, thuth@redhat.com,
lvivier@redhat.com, qemu-devel@nongnu.org, jdenemar@redhat.com
Subject: Re: [External] Re: [PATCH v2 4/7] migration/multifd: Enable zero page checking from multifd threads.
Date: Mon, 26 Feb 2024 09:43:19 +0800 [thread overview]
Message-ID: <Zdvst5RmG73_5aWo@x1n> (raw)
In-Reply-To: <CAAYibXgp-NGqE5ATby_Y6=s7WR5yToTxWQbdeVydv0Jez98iEQ@mail.gmail.com>
On Sat, Feb 24, 2024 at 03:03:15PM -0800, Hao Xiang wrote:
> So I just want to make sure I am coding the right solution. I added
> setting "zero-page-detection" to "legacy" in hw_compat_8_2 and tested
> it. The behavior is that if I set machine type to pc-q35-8.2,
> zero-page-detection will automatically be set to "legacy". But if I
> set the machine type to pc-q35-9.0, zero-page-detection will be the
> default value "multifd". However, this doesn't seem to be a hard
> requirement because I can still override zero-page-detection to
> multifd on machine type pc-q35-8.2. Is this OK?
What we want to guarantee is old 8.2 users can smoothly migrate to the new
qemus, and existing 8.2 (or prior) users definitely don't have any override
over the new parameter zero-page-detection simply because 8.2 (or prior)
binary doesn't support it yet.
Then, if someone is using new binary with 8.2 machine types, meanwhile
override this default value, it means it's the user's choice of doing this,
and the user should guarantee all the qemus he/she manages also keeps this
parameter override to make sure migration will work between these qemu
processes.
So in short, that's all fine.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-02-26 1:44 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 22:39 [PATCH v2 0/7] Introduce multifd zero page checking Hao Xiang
2024-02-16 22:39 ` [PATCH v2 1/7] migration/multifd: Add new migration option zero-page-detection Hao Xiang
2024-02-21 12:03 ` Markus Armbruster
2024-02-23 4:22 ` [External] " Hao Xiang
2024-02-21 13:58 ` Elena Ufimtseva
2024-02-23 4:37 ` [External] " Hao Xiang
2024-02-22 10:36 ` Peter Xu
2024-02-26 7:18 ` Wang, Lei
2024-02-26 19:45 ` [External] " Hao Xiang
2024-02-16 22:39 ` [PATCH v2 2/7] migration/multifd: Support for zero pages transmission in multifd format Hao Xiang
2024-02-21 15:37 ` Elena Ufimtseva
2024-02-23 4:18 ` [External] " Hao Xiang
2024-02-16 22:39 ` [PATCH v2 3/7] migration/multifd: Zero page transmission on the multifd thread Hao Xiang
2024-02-16 23:49 ` Richard Henderson
2024-02-23 4:38 ` [External] " Hao Xiang
2024-02-24 19:06 ` Hao Xiang
2024-02-21 12:04 ` Markus Armbruster
2024-02-21 16:00 ` Elena Ufimtseva
2024-02-23 4:59 ` [External] " Hao Xiang
2024-02-21 21:04 ` Fabiano Rosas
2024-02-23 2:20 ` Peter Xu
2024-02-23 5:15 ` [External] " Hao Xiang
2024-02-24 22:56 ` Hao Xiang
2024-02-26 1:30 ` Peter Xu
2024-02-23 5:18 ` Hao Xiang
2024-02-23 14:47 ` Fabiano Rosas
2024-02-16 22:39 ` [PATCH v2 4/7] migration/multifd: Enable zero page checking from multifd threads Hao Xiang
2024-02-21 16:11 ` Elena Ufimtseva
2024-02-23 5:24 ` [External] " Hao Xiang
2024-02-21 21:06 ` Fabiano Rosas
2024-02-23 2:33 ` Peter Xu
2024-02-23 6:02 ` [External] " Hao Xiang
2024-02-24 23:03 ` Hao Xiang
2024-02-26 1:43 ` Peter Xu [this message]
2024-02-23 5:47 ` Hao Xiang
2024-02-23 14:38 ` Fabiano Rosas
2024-02-16 22:40 ` [PATCH v2 5/7] migration/multifd: Add new migration test cases for legacy zero page checking Hao Xiang
2024-02-21 20:59 ` Fabiano Rosas
2024-02-23 4:20 ` [External] " Hao Xiang
2024-02-16 22:40 ` [PATCH v2 6/7] migration/multifd: Add zero pages and zero bytes counter to migration status interface Hao Xiang
2024-02-21 12:07 ` Markus Armbruster
2024-02-16 22:40 ` [PATCH v2 7/7] Update maintainer contact for migration multifd zero page checking acceleration Hao Xiang
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=Zdvst5RmG73_5aWo@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=hao.xiang@bytedance.com \
--cc=jdenemar@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.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 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).