qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org,
	"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Avihai Horon" <avihaih@nvidia.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Prasad Pandit" <ppandit@redhat.com>
Subject: Re: [PATCH v2 3/7] migration/ram: Move RAM_SAVE_FLAG* into ram.h
Date: Fri, 6 Dec 2024 10:46:07 -0500	[thread overview]
Message-ID: <Z1McP5JSSMNAHGGk@x1n> (raw)
In-Reply-To: <87ldwsc0eh.fsf@suse.de>

On Fri, Dec 06, 2024 at 12:10:46PM -0300, Fabiano Rosas wrote:
> > Wanna me to add a comment for that in this patch?
> 
> Yes, please.

When I did it, I also did a few other things:

  - Rearranged the comment section, put all things together
  - Remove RAM_SAVE_FLAG_ZERO directly
  - Reindents

The plan is to squash below diff in v3 post, feel free to comment before
that.

===8<===
From 593227f1b9e678418f5b99ac51525884fa0adfc6 Mon Sep 17 00:00:00 2001
From: Peter Xu <peterx@redhat.com>
Date: Fri, 6 Dec 2024 10:43:25 -0500
Subject: [PATCH] fixup! migration/ram: Move RAM_SAVE_FLAG* into ram.h

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 migration/ram.h | 33 ++++++++++++++++++---------------
 migration/ram.c | 22 ++++++++++------------
 2 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/migration/ram.h b/migration/ram.h
index cfdcccd266..921c39a2c5 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -39,24 +39,27 @@
  * it to only search for the zero value.  And to avoid confusion with
  * RAM_SAVE_FLAG_COMPRESS_PAGE just rename it.
  *
- * RAM_SAVE_FLAG_FULL was obsoleted in 2009.
+ * RAM_SAVE_FLAG_FULL (0x01) was obsoleted in 2009.
  *
  * RAM_SAVE_FLAG_COMPRESS_PAGE (0x100) was removed in QEMU 9.1.
+ *
+ * RAM_SAVE_FLAG_HOOK is only used in RDMA. Whenever this is found in the
+ * data stream, the flags will be passed to rdma functions in the
+ * incoming-migration side.
+ *
+ * We can't use any flag that is bigger than 0x200, because the flags are
+ * always assumed to be encoded in a ramblock address offset, which is
+ * multiple of PAGE_SIZE.  Here it means QEMU supports migration with any
+ * architecture that has PAGE_SIZE>=1K (0x400).
  */
-#define RAM_SAVE_FLAG_FULL     0x01
-#define RAM_SAVE_FLAG_ZERO     0x02
-#define RAM_SAVE_FLAG_MEM_SIZE 0x04
-#define RAM_SAVE_FLAG_PAGE     0x08
-#define RAM_SAVE_FLAG_EOS      0x10
-#define RAM_SAVE_FLAG_CONTINUE 0x20
-#define RAM_SAVE_FLAG_XBZRLE   0x40
-/*
- * ONLY USED IN RDMA: Whenever this is found in the data stream, the flags
- * will be passed to rdma functions in the incoming-migration side.
- */
-#define RAM_SAVE_FLAG_HOOK     0x80
-#define RAM_SAVE_FLAG_MULTIFD_FLUSH    0x200
-/* We can't use any flag that is bigger than 0x200 */
+#define RAM_SAVE_FLAG_ZERO                    0x002
+#define RAM_SAVE_FLAG_MEM_SIZE                0x004
+#define RAM_SAVE_FLAG_PAGE                    0x008
+#define RAM_SAVE_FLAG_EOS                     0x010
+#define RAM_SAVE_FLAG_CONTINUE                0x020
+#define RAM_SAVE_FLAG_XBZRLE                  0x040
+#define RAM_SAVE_FLAG_HOOK                    0x080
+#define RAM_SAVE_FLAG_MULTIFD_FLUSH           0x200
 
 extern XBZRLECacheStats xbzrle_counters;
-- 
2.47.0


-- 
Peter Xu



  reply	other threads:[~2024-12-06 15:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06  0:58 [PATCH v2 0/7] migration/multifd: Some VFIO / postcopy preparations on flush Peter Xu
2024-12-06  0:58 ` [PATCH v2 1/7] migration/multifd: Further remove the SYNC on complete Peter Xu
2024-12-06 13:17   ` Fabiano Rosas
2024-12-06 14:40     ` Peter Xu
2024-12-06  0:58 ` [PATCH v2 2/7] migration/multifd: Allow to sync with sender threads only Peter Xu
2024-12-06 13:26   ` Fabiano Rosas
2024-12-06 14:50     ` Peter Xu
2024-12-06 15:00       ` Fabiano Rosas
2024-12-06  0:58 ` [PATCH v2 3/7] migration/ram: Move RAM_SAVE_FLAG* into ram.h Peter Xu
2024-12-06 13:43   ` Fabiano Rosas
2024-12-06 15:03     ` Peter Xu
2024-12-06 15:10       ` Fabiano Rosas
2024-12-06 15:46         ` Peter Xu [this message]
2024-12-06 16:58           ` Fabiano Rosas
2024-12-06  0:58 ` [PATCH v2 4/7] migration/multifd: Unify RAM_SAVE_FLAG_MULTIFD_FLUSH messages Peter Xu
2024-12-06 14:12   ` Fabiano Rosas
2024-12-06  0:58 ` [PATCH v2 5/7] migration/multifd: Remove sync processing on postcopy Peter Xu
2024-12-06 14:19   ` Fabiano Rosas
2024-12-06  0:58 ` [PATCH v2 6/7] migration/multifd: Cleanup src flushes on condition check Peter Xu
2024-12-06 14:18   ` Fabiano Rosas
2024-12-06 15:13     ` Peter Xu
2024-12-06  0:58 ` [PATCH v2 7/7] migration/multifd: Document the reason to sync for save_setup() Peter Xu
2024-12-06 14:40   ` Fabiano Rosas
2024-12-06 15:36     ` Peter Xu
2024-12-06 17:01       ` 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=Z1McP5JSSMNAHGGk@x1n \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=clg@redhat.com \
    --cc=farosas@suse.de \
    --cc=mail@maciej.szmigiero.name \
    --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).