On Wed, 16 Jul 2025 at 19:06, Fabiano Rosas wrote:
> The condition should be >=.
* I'm thinking of doing away with the loop and the string array. The
array has 3 values of which only one gets used due to conversion to
seconds.
> But then that's "0 sec" for 100 us.
#define US (MS * 1000) =>
On Tue, 15 Jul 2025 at 18:49, Fabiano Rosas wrote:
> @@ -57,11 +57,9 @@ static const gchar *format_time_str(uint64_t us)
> const char *units[] = {"us", "ms", "sec"};
> int index = 0;
>
> -while (us > 1000) {
> +while (us > 1000 && index + 1 < ARRAY_SIZE(units)) {
> us /=
hp_state,
> &vmstate_cpuhp_state,
> &vmstate_ghes_state,
> +&vmstate_pcihp_state,
> NULL
> }
> };
> --
Looks okay.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hi,
On Mon, 12 May 2025 at 18:22, Prasad Pandit wrote:
> From: Prasad Pandit
>
> Add new qtests to run postcopy migration with multifd
> channels enabled.
>
> Signed-off-by: Prasad Pandit
> ---
> tests/qtest/migration/compression-tests.c | 18
> tests/qtest
On Fri, 9 May 2025 at 20:00, Peter Xu wrote:
> diff --git a/tests/qtest/migration/precopy-tests.c
> b/tests/qtest/migration/precopy-tests.c
> index a575791c72..441a65bcf5 100644
> --- a/tests/qtest/migration/precopy-tests.c
> +++ b/tests/qtest/migration/precopy-tests.c
> @@ -34,7 +34,6 @@
> #def
From: Prasad Pandit
Add new qtests to run postcopy migration with multifd
channels enabled.
Signed-off-by: Prasad Pandit
---
tests/qtest/migration/compression-tests.c | 18
tests/qtest/migration/postcopy-tests.c| 27
tests/qtest/migration/precopy-tests.c | 28
From: Prasad Pandit
Enable Multifd and Postcopy migration together.
The migration_ioc_process_incoming() routine checks
magic value sent on each channel and helps to properly
setup multifd and postcopy channels.
The Precopy and Multifd threads work during the initial
guest RAM transfer. When
From: Prasad Pandit
During multifd migration, zero pages are written if
they are migrated more than once.
This may result in a migration thread hang issue when
multifd and postcopy are enabled together.
When postcopy is enabled, always write zero pages as and
when they are migrated.
Signed
From: Prasad Pandit
Hello,
* This series (v11) fixes spelling and capitalisations glitches and
does some refactoring and reordering changes as suggested in the
review of v10.
===
67/67 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test OK
196.69s 81
Hi,
On Fri, 9 May 2025 at 20:41, Peter Xu wrote:
> Isn't that what multifd is doing already?
> typedef struct {
> ...
> /*
> * This array contains the pointers to:
> * - normal pages (initial normal_pages entries)
> * - zero pages (following zero_pages entries)
> */
> > This patch should come before 1/3, otherwise it'll break bisect.
> We could squash the two together, IMHO.
* It is adjusting the specific optimisation behaviour for the use case
of when Multifd and Postcopy are enabled together. I think it's better
as a separate patch. It'll help to see how th
On Thu, 8 May 2025 at 19:27, Fabiano Rosas wrote:
> > During multifd migration, zero pages are are written if
> > they are migrated more than ones.
>
> s/ones/once/
> s/ones/once/
> extra blank line here^
>
> nit: Inconsistent use of capitalization for the feature names. I'd keep
> it all lowercas
On Fri, 9 May 2025 at 00:34, Peter Xu wrote:
> I may not have followed the whole discussions, but have you tried to avoid
> this global?
-> https://lore.kernel.org/qemu-devel/875xkyyxyy@suse.de/
* Yes, it was discussed, passing it as a parameter would change the
function prototype and en
From: Prasad Pandit
Hello,
* This series (v10) fixes the migration hang issue caused by optimised
writing of the zero pages during multifd phase. It also fixes the qtest
failure caused by missing 'env->has_uffd' check before running a postcopy
test.
Some of the patches f
From: Prasad Pandit
Enable Multifd and Postcopy migration together.
The migration_ioc_process_incoming() routine checks
magic value sent on each channel and helps to properly
setup multifd and postcopy channels.
The Precopy and Multifd threads work during the initial
guest RAM transfer. When
From: Prasad Pandit
Add new qtests to run postcopy migration with multifd
channels enabled.
Signed-off-by: Prasad Pandit
---
tests/qtest/migration/compression-tests.c | 18
tests/qtest/migration/postcopy-tests.c| 27
tests/qtest/migration/precopy-tests.c | 22
From: Prasad Pandit
During multifd migration, zero pages are are written if
they are migrated more than ones.
This may result in a migration hang issue when Multifd
and Postcopy are enabled together.
When Postcopy is enabled, always write zero pages as and
when they are migrated.
Signed-off
Hi,
On Tue, 6 May 2025 at 00:34, Fabiano Rosas wrote:
> >> # Running /ppc64/migration/multifd+postcopy/tcp/plain/cancel
> >> # Using machine type: pseries-10.0
> >> # starting QEMU: exec ./qemu-system-ppc64 -qtest
> >> # {
> >> # "error": {
> >> # "class": "GenericError",
> >> #
Hello Fabiano,
On Tue, 6 May 2025 at 00:31, Fabiano Rosas wrote:
> > +++ b/migration/multifd-zero-page.c
> > @@ -85,9 +85,11 @@ void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> > {
> > for (int i = 0; i < p->zero_num; i++) {
> > void *page = p->host + p->zero[i];
> > -
On Tue, 29 Apr 2025 at 19:18, Peter Xu wrote:
> Please don't rush to send. Again, let's verify the issue first before
> resending anything.
>
> If you could reproduce it it would be perfect, then we can already verify
> it. Otherwise we may need help from Fabiano. Let's not send anything if
> yo
On Tue, 29 Apr 2025 at 18:34, Peter Xu wrote:
> I think that's what Fabiano mentioned, but ultimately we need to verify it
> on a reproducer to know.
...
> Looks ok, but please add some comments explain why postcopy needs to do it,
> and especially do it during precopy phase.
>
> I'd use migrate_p
Hi,
> On Thu, Apr 17, 2025 at 01:05:37PM -0300, Fabiano Rosas wrote:
> > It's not that page faults happen during multifd. The page was already
> > sent during precopy, but multifd-recv didn't write to it, it just marked
> > the receivedmap. When postcopy starts, the page gets accessed and
> > faul
Hi,
On Wed, 16 Apr 2025 at 18:29, Fabiano Rosas wrote:
> > 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
On Tue, 15 Apr 2025 at 16:33, Daniel P. Berrangé wrote:
> Because that's what the QEMU API specification declares
> * Not all implementations will support this facility, so may report
> * an error. To avoid errors, the caller may check for the feature
> * flag QIO_CHANNEL_FEATURE_SEEKABLE prior
Hi,
On Tue, 15 Apr 2025 at 15:51, Daniel P. Berrangé wrote:
> It is actually NOT really connected to lseek, and as such
* For file and fd channels _FEATURE_SEEKABLE is set when/if lseek(2) works.
->
https://gitlab.com/qemu-project/qemu/-/commit/401e311ff72e0a62c834bfe466de68a82cfd90cb
>
From: Peter Xu
Implement save_postcopy_prepare(), preparing for the enablement
of both multifd and postcopy.
Signed-off-by: Peter Xu
Signed-off-by: Prasad Pandit
---
migration/ram.c | 37 +
1 file changed, 37 insertions(+)
v8: reorder patch and some
igned-off-by: Peter Xu
Signed-off-by: Prasad Pandit
---
include/migration/register.h | 15 +++
migration/migration.c| 4
migration/savevm.c | 33 +
migration/savevm.h | 1 +
4 files changed, 53 insertions(+)
v8: reorder
From: Prasad Pandit
Add new qtests to run postcopy migration with multifd
channels enabled.
Signed-off-by: Prasad Pandit
---
tests/qtest/migration/compression-tests.c | 16
tests/qtest/migration/postcopy-tests.c| 27 +
tests/qtest/migration/precopy-tests.c | 19
From: Prasad Pandit
Enable Multifd and Postcopy migration together.
The migration_ioc_process_incoming() routine checks
magic value sent on each channel and helps to properly
setup multifd and postcopy channels.
The Precopy and Multifd threads work during the initial
guest RAM transfer. When
From: Prasad Pandit
The various logical migration channels don't have a
standardized way of advertising themselves and their
connections may be seen out of order by the migration
destination. When a new connection arrives, the incoming
migration currently make use of heuristics to dete
From: Prasad Pandit
Migration capabilities are set in multiple '.start_hook'
functions for various tests. Instead, consolidate setting
capabilities in 'migrate_start_set_capabilities()' function
which is called from the 'migrate_start()' function.
While simplifyin
From: Prasad Pandit
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
From: Prasad Pandit
Move MULTIFD_ macros to the header file so that
they are accessible from other source files.
Reviewed-by: Fabiano Rosas
Signed-off-by: Prasad Pandit
---
migration/multifd.c | 5 -
migration/multifd.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
v8: no
Hi,
On Fri, 11 Apr 2025 at 01:48, Fabiano Rosas wrote:
> That's what it looks like. It could be some error condition that is not
> being propagated properly. The thread hits an error and exits without
> informing the rest of migration.
* The gdb(1) hanging in the postcopy_ram_fault_thread() is n
On Mon, 7 Apr 2025 at 14:31, Marco Cavenati wrote:
> As you said the capability is used internally. Its goal is to signal to
> other QEMU code that the QIOChannel is seekable.
> 'qio_channel_pwritev' and 'qio_channel_preadv' can be used only if
> the QIOChannel has the 'QIO_CHANNEL_FEATURE_SEEKABL
Hello Fabiano,
On Thu, 3 Apr 2025 at 18:41, Fabiano Rosas wrote:
> Prasad Pandit writes:
> > * Thank you for the reproducer and traces. I'll try to check more and
> > see if I'm able to reproduce it on my side.
>
> Thanks. I cannot merge this series unti
Hi,
On Fri, 4 Apr 2025 at 17:35, Marco Cavenati wrote:
> The QIO_CHANNEL_FEATURE_SEEKABLE flag is set to indicate that
> the channel supports seekable operations. This flag is more about
> signaling capability rather than dictating the use of the specific
> lseek(2) function.
* Yes.
> In this c
On Thu, 20 Mar 2025 at 20:15, Fabiano Rosas wrote:
> Technically both can happen. But that would just be the case of
> file:fdset migration which requires an extra fd for O_DIRECT. So
> "multiple" in the usual sense of "more is better" is only
> fd-per-thread. IOW, using multiple fds is an impleme
From: Prasad Pandit
Move MULTIFD_ macros to the header file so that
they are accessible from other source files.
Reviewed-by: Fabiano Rosas
Signed-off-by: Prasad Pandit
---
migration/multifd.c | 5 -
migration/multifd.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
v7: no
On Tue, 11 Mar 2025 at 21:44, wrote:
> From: Marc-André Lureau
>
> Fixes: https://issues.redhat.com/browse/RHEL-81894
> Signed-off-by: Marc-André Lureau
* No commit message? Same for patch 09/10.
---
- Prasad
On Fri, 21 Mar 2025 at 15:49, Cédric Le Goater wrote:
> So you mean open coding :
> if (migration_is_running()) {
> migration_file_set_error(ret, errp);
> }
> ?
* Yes.
> Yes. I think it is a good idea to limit proliferation of this wrapper.
> Ideally, we wouldn't need to use m
On Thu, 3 Apr 2025 at 18:37, Fabiano Rosas wrote:
> The code assumes some understanding of the multifd sync in general. It
> doesn't help that we don't have a high level documentation for that
> (yet). If you think the comments at the MultiFDSyncReq are not enough,
> feel free to propose a separat
Hi,
On Fri, 4 Apr 2025 at 14:35, Marco Cavenati wrote:
> Almost. Unlike lseek(2), pread(2) and co. do not have side effects on the
> fd's offset.
> From the man page:
> > The pread() and pwrite() system calls are especially useful in
> > multithreaded applications. They allow multiple threads
On Thu, 3 Apr 2025 at 18:29, Fabiano Rosas wrote:
> Yes, there's no point. if we already have main and multifd channels,
> what's left must be postcopy.
* Okay.
> Well, but don't add it blindly if it doesn't make sense.
* Hmmn, okay. When I say/do things that seem reasonable to me, I'm
told - i
On Thu, 27 Mar 2025 at 20:03, Marco Cavenati wrote:
> Enable the use of the mapped-ram migration feature with savevm/loadvm
> snapshots by adding the QIO_CHANNEL_FEATURE_SEEKABLE feature to
> QIOChannelBlock. Implement io_preadv and io_pwritev methods to provide
> positioned I/O capabilities that
On Mon, 31 Mar 2025 at 20:57, Fabiano Rosas wrote:
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -1297,7 +1297,7 @@ static int find_dirty_block(RAMState *rs,
> > PageSearchStatus *pss)
> > pss->page = 0;
> > pss->block = QLIST_NEXT_RCU(pss->block, next);
> >
On Tue, 1 Apr 2025 at 02:24, Fabiano Rosas wrote:
> The postcopy/multifd/plain test is still hanging from time to time. I
> see a vmstate load function trying to access guest memory and the
> postcopy-listen thread already finished, waiting for that
> qemu_loadvm_state() (frame #18) to return and
Hi,
On Mon, 31 Mar 2025 at 20:49, Fabiano Rosas wrote:
> > +static bool ram_save_postcopy_prepare(QEMUFile *f, void *opaque, Error
> > **errp)
> > +{
> > +int ret;
> > +
> > +if (migrate_multifd()) {
> > +/*
> > + * When multifd is enabled, source QEMU needs to make sure
On Mon, 31 Mar 2025 at 20:39, Fabiano Rosas wrote:
> This patch and the next one need to come before 3/7.
* Okay.
Thank you.
---
- Prasad
Hello Fabiano,
On Mon, 31 Mar 2025 at 20:31, Fabiano Rosas wrote:
> > +} else if (mis->from_src_file) {
> This is redundant.
* This was to ensure (double check) that when the Postcopy connection
comes in, the main channel is established. Also a couple of versions
back migration qtest was fai
On Thu, 27 Mar 2025 at 20:05, Fabiano Rosas wrote:
> I'll get to it soon. I need to send a PR for the recent SNP breakage and
> also check Li Zhijian's RDMA series first.
* I see, okay. Thank you for an update, I appreciate it.
Thank you.
---
- Prasad
On Thu, 27 Mar 2025 at 16:15, Zheng Huang wrote:
> +++ b/hw/net/virtio-net.c
> @@ -422,7 +422,7 @@ static void virtio_net_set_status(struct VirtIODevice
> *vdev, uint8_t status)
> }
> } else {
> if (q->tx_timer) {
> -timer_del(q->tx_timer);
> +
Hello,
On Thu, 27 Mar 2025 at 16:59, Zheng Huang wrote:
> This patch addresses a memory leak bug in the usages of `timer_del()`.
> The issue arisesfrom the incorrect use of the ambiguous timer API
> `timer_del()`, which does not free the timer object. The leak sanitizer
> report this issue during
migration/qemu-file.h"
> #include "migration-multifd.h"
> +#include "vfio-migration-internal.h"
> #include "trace.h"
>
> #define VFIO_DEVICE_STATE_CONFIG_STATE (1)
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index
> 96d294794bc3056baa3b0b4e23488402db5de797..2a72a8e07542096276cc7c386359ad375e7d24c8
> 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -31,6 +31,7 @@
> #include "pci.h"
> #include "trace.h"
> #include "hw/hw.h"
> +#include "vfio-migration-internal.h"
>
> /*
> * This is an arbitrary size based on migration of mlx5 devices, where
> typically
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index
> 7f1532fbed9aed2eae2c98f6fd79a9056ff1e84f..158deca06cb240622a254f5059c47873e5fcc7de
> 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -44,6 +44,7 @@
> #include "migration/blocker.h"
> #include "migration/qemu-file.h"
> #include "system/iommufd.h"
> +#include "vfio-migration-internal.h"
>
> #define TYPE_VFIO_PCI_NOHOTPLUG "vfio-pci-nohotplug"
>
> --
* Looks okay.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
#ifdef CONFIG_VFIO
> void migration_populate_vfio_info(MigrationInfo *info)
> {
> -if (vfio_mig_active()) {
> +if (vfio_migration_active()) {
> info->vfio = g_malloc0(sizeof(*info->vfio));
> -info->vfio->transferred = vfio_mig_bytes_transferred();
> +info->vfio->transferred = vfio_migration_bytes_transferred();
> }
> }
>
> void migration_reset_vfio_bytes_transferred(void)
> {
> -vfio_mig_reset_bytes_transferred();
> +vfio_migration_reset_bytes_transferred();
> }
> #else
> void migration_populate_vfio_info(MigrationInfo *info)
> --
* Looks okay.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
tion->device_state == VFIO_DEVICE_STATE_RUNNING ||
> + migration->device_state == VFIO_DEVICE_STATE_RUNNING_P2P;
> +}
> +
> +bool vfio_device_state_is_precopy(VFIODevice *vbasedev)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +
> +return migration->device_state == VFIO_DEVICE_STATE_PRE_COPY ||
> + migration->device_state == VFIO_DEVICE_STATE_PRE_COPY_P2P;
> +}
> --
* Looks okay.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hello Fabiano,
On Tue, 18 Mar 2025 at 18:10, Prasad Pandit wrote:
> * This series (v8) splits earlier patch-2 which enabled multifd and
> postcopy options together into two separate patches. One modifies
> the channel discovery in migration_ioc_process_incoming() function,
> an
Hi,
On Fri, 21 Mar 2025 at 19:34, Fabiano Rosas wrote:
> Well, I can't speak for everyone, of course, but generally the less
> layers on top of the object of your work the better.
* Yes, true.
> There are several ways of accessing QMP, some examples I have lying
> around:
>
> ==
> $QEMU ... -
On Tue, 11 Mar 2025 at 00:59, Fabiano Rosas wrote:
> Peter Xu writes:
> > To me, this is a fairly important question to ask. Fundamentally, the very
> > initial question is why do we need periodic flush and sync at all. It's
> > because we want to make sure new version of pages to land later th
Hello Fabiano,
* First big thank you for starting/writing this document. It is a
great resource.
On Fri, 7 Mar 2025 at 19:13, Fabiano Rosas wrote:
> +++ b/docs/devel/migration/multifd.rst
> @@ -0,0 +1,254 @@
> +Multifd
> +Multifd is the name given for the migration capability that enables
> +dat
On Wed, 19 Mar 2025 at 22:57, Cédric Le Goater wrote:
> you are right. I am not satisfied with the header file names.
>
> It has been problematic and I would prefer all header files to have
> a "vfio-" prefix. Sadly, the gcc command line is making it difficult,
> or I misunderstood some parts.
>
>
tate.h"
> diff --git a/migration/target.c b/migration/target.c
> index
> f5d8cfe7c2a3473f4bd3f5068145598c60973c58..e1eacd1db7a471cba51b4e257a834eb7581f9671
> 100644
> --- a/migration/target.c
> +++ b/migration/target.c
> @@ -11,7 +11,7 @@
> #include CONFIG_DEVICES
>
> #ifdef CONFIG_VFIO
> -#include "hw/vfio/vfio-common.h"
> +#include "hw/vfio/vfio-migration.h"
> #endif
>
> #ifdef CONFIG_VFIO
> --
> 2.48.1
* Looks okay. With above text corrections, reviewed by: Prasad Pandit
Thank you.
---
- Prasad
+bool vfio_device_state_is_running(VFIODevice *vbasedev)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +
> +return migration->device_state == VFIO_DEVICE_STATE_RUNNING ||
> + migration->device_state == VFIO_DEVICE_STATE_RUNNING_P2P;
> +}
> +
> +bool vfio_device_state_is_precopy(VFIODevice *vbasedev)
> +{
> +VFIOMigration *migration = vbasedev->migration;
> +
> +return migration->device_state == VFIO_DEVICE_STATE_PRE_COPY ||
> + migration->device_state == VFIO_DEVICE_STATE_PRE_COPY_P2P;
> +}
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index
> 7f1532fbed9aed2eae2c98f6fd79a9056ff1e84f..3612f6fe7d0864fe3789f4ea221da01ef87d0664
> 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -44,6 +44,7 @@
> #include "migration/blocker.h"
> #include "migration/qemu-file.h"
> #include "system/iommufd.h"
> +#include "migration.h"
>
> #define TYPE_VFIO_PCI_NOHOTPLUG "vfio-pci-nohotplug"
>
* Change looks okay. The header name 'migration.h' is rather generic,
vfio-migration.h could be better. Looking at - #include "migration.h"
- it is not clear which migration.h is being included. There is also a
migration/migration.h header. But I'll leave that to you. (just
sharing thoughts)
Reviewed by: Prasad Pandit
Thank you.
---
- Prasad
On Tue, 18 Mar 2025 at 15:29, Cédric Le Goater wrote:
> This routine is related to VFIO migration. It belongs to "migration.c".
> While at it, rename it to better reflect the namespace it belongs to.
>
> Signed-off-by: Cédric Le Goater
> ---
> hw/vfio/migration.h | 1 +
> hw/vfio/dirty-tra
From: Prasad Pandit
Add new qtests to run postcopy migration with multifd
channels enabled.
Signed-off-by: Prasad Pandit
---
tests/qtest/migration/compression-tests.c | 16
tests/qtest/migration/postcopy-tests.c| 27 +
tests/qtest/migration/precopy-tests.c | 19
From: Prasad Pandit
Enable Multifd and Postcopy migration together.
The migration_ioc_process_incoming() routine
checks magic value sent on each channel and
helps to properly setup multifd and postcopy
channels.
The Precopy and Multifd threads work during the
initial guest RAM transfer. When
From: Prasad Pandit
Hello,
* This series (v8) splits earlier patch-2 which enabled multifd and
postcopy options together into two separate patches. One modifies
the channel discovery in migration_ioc_process_incoming() function,
and second one enables the multifd and postcopy migration
From: Peter Xu
Implement save_postcopy_prepare(), preparing for the enablement of both
multifd and postcopy.
Please see the rich comment for the rationals.
Signed-off-by: Peter Xu
Signed-off-by: Prasad Pandit
---
migration/ram.c | 37 +
1 file changed, 37
igned-off-by: Peter Xu
Signed-off-by: Prasad Pandit
---
include/migration/register.h | 15 +++
migration/migration.c| 4
migration/savevm.c | 33 +
migration/savevm.h | 1 +
4 files changed, 53 insertions(+)
v8:
- New
From: Prasad Pandit
The various logical migration channels don't have a
standardized way of advertising themselves and their
connections may be seen out of order by the migration
destination. When a new connection arrives, the incoming
migration currently make use of heuristics to dete
From: Prasad Pandit
Migration capabilities are set in multiple '.start_hook'
functions for various tests. Instead, consolidate setting
capabilities in 'migrate_start_set_capabilities()' function
which is called from the 'migrate_start()' function.
While simplifyin
Hi,
On Fri, 14 Mar 2025 at 01:40, Peter Xu wrote:
>+save_section_header(f, se, QEMU_VM_SECTION_PART);
> +ram_save_zero_page(f, se->opaque);
>I'll stop requesting a why here...
* Earlier in this thread you mentioned 'We need a header'. I took it
as a 'RAM page' header, not save_se
Hello Peter,
On Sat, 8 Mar 2025 at 04:18, Peter Xu wrote:
> [1]
> Please move all of them at the entry of postcopy_start().
> I still like the name I provided because it's more generic, above [1].
> Maybe it should be SECTION_PART. So we provide all iterator a chance to
> do something right bef
Hi,
On Tue, 11 Mar 2025 at 01:28, Fabiano Rosas wrote:
> They occur when cleanup code is allowed to run when resources have not
> yet been allocated or while the resources are still being accessed.
>
> Having the shutdown routine at a single point when it's clear everything
> else is ready for sh
On Mon, 10 Mar 2025 at 20:09, Fabiano Rosas wrote:
> Good point. Shutdown at random places makes it difficult to protect
> against cleanup races.
* Just to understand, how and where do these races occur?
Thank you.
---
- Prasad
Hi,
On Sat, 8 Mar 2025 at 04:18, Peter Xu wrote:
> Please move all of them at the entry of postcopy_start().
* Okay.
> [1]
>
> > +int qemu_savevm_state_complete_multifd(QEMUFile *f)
> I still like the name I provided because it's more generic, above [1].
===
> Maybe the easiest as of now is o
Hello Fabiano,
On Wed, 5 Mar 2025 at 19:26, Fabiano Rosas wrote:
> Note that none of this is out of the ordinary, you'll find such
> discussions in any thread on this community. It may feel arbitrary to
> you because that's tacit knowledge we gathered along the years.
* I understand. I don't fin
Hello Peter,
On Wed, 5 Mar 2025 at 18:24, Peter Xu wrote:
> > On Tue, 4 Mar 2025 at 20:05, Peter Xu wrote:
> > > I think we need the header, the ram is a module.
> > > Do similarly like qemu_savevm_state_complete_precopy_iterable() but do
> > > whatever a vmstate hander wants, so it'll be with a
Hi,
On Tue, 4 Mar 2025 at 20:05, Peter Xu wrote:
> I think we need the header, the ram is a module.
> Do similarly like qemu_savevm_state_complete_precopy_iterable() but do
> whatever a vmstate hander wants, so it'll be with a header.
* I don't fully see yet how this shall work.
> Please consid
Hi,
On Tue, 4 Mar 2025 at 20:12, Peter Xu wrote:
> IIUC Fabiano is not asking you to drop them, but split them. Split still
> "requires" them to be present, as long as before the enablement patch.
* Yes, same here; Even I am not suggesting to drop anything. Fabiano
mentioned the following about
Hi,
On Mon, 3 Mar 2025 at 19:42, Peter Xu wrote:
> On Mon, Mar 03, 2025 at 04:17:53PM +0530, Prasad Pandit wrote:
> > * I think we (you, me, Peter) are all looking at things differently.
> > - In my view Patch-2 is the minimal change _required_ to enable
> > multifd &am
Hello Peter,
On Mon, 3 Mar 2025 at 20:20, Peter Xu wrote:
> We need the header.
* We need a section type, which is sent by qemu_savevm_command_send()
as 'QEMU_VM_COMMAND'.
> Maybe the easiest as of now is one more hook like
> qemu_savevm_state_complete_precopy_prepare(), and only use it in RAM
Hello Fabiano,
On Fri, 28 Feb 2025 at 20:23, Fabiano Rosas wrote:
> You forgot to split patch 2. We cannot have a commit that revamps the
> channel discovery logic and enables a new feature at the same
> time. Changing the channel discovery affects all the migration
> use-cases, that change canno
Hello Peter,
On Fri, 28 Feb 2025 at 19:13, Peter Xu wrote:
> We should be able to do multifd's flush and sync before VM
> stopped in postcopy_start()..
>
> What I actually think the easiest is to do flush and sync once in
> postcopy_start() as mentioned above. I think that'll serialize with
> po
On Fri, 28 Feb 2025 at 20:41, Fabiano Rosas wrote:
> > +static void test_multifd_postcopy_tcp_tls_psk_match(void)
> > +{
> > +MigrateCommon args = {
> > +.start = {
> > +.caps[MIGRATION_CAPABILITY_MULTIFD] = true,
>
> Missing POSTCOPY_RAM here, no?
Yes, will fix it.
Thank
From: Prasad Pandit
Add new qtests to run postcopy migration with multifd
channels enabled.
Signed-off-by: Prasad Pandit
---
tests/qtest/migration/compression-tests.c | 15
tests/qtest/migration/postcopy-tests.c| 27 +
tests/qtest/migration/precopy-tests.c | 19
From: Prasad Pandit
Move MULTIFD_ macros to the header file so that
they are accessible from other source files.
Reviewed-by: Fabiano Rosas
Signed-off-by: Prasad Pandit
---
migration/multifd.c | 5 -
migration/multifd.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
v6: no
From: Prasad Pandit
When Multifd and Postcopy migration is enabled together,
before starting Postcopy phase, Multifd threads are shutdown.
But before this shutdown, we need to flush the Multifd channels
on the source side and notify the destination migration thread
to synchronise with the
From: Prasad Pandit
Enable Multifd and Postcopy migration together.
The migration_ioc_process_incoming() routine
checks magic value sent on each channel and
helps to properly setup multifd and postcopy
channels.
The Precopy and Multifd threads work during the
initial guest RAM transfer. When
From: Prasad Pandit
Migration capabilities are set in multiple '.start_hook'
functions for various tests. Instead, consolidate setting
capabilities in 'migrate_start_set_capabilities()' function
which is called from the 'migrate_start()' function.
While simplifyin
From: Prasad Pandit
Hello,
* This series (v7) adds 'MULTIFD_RECV_SYNC' migration command. It is used
to notify the destination migration thread to synchronise with the Multifd
threads. This allows Multifd ('mig/dst/recv_x') threads on the destination
to receive all the
Hello Fabiano,
On Tue, 18 Feb 2025 at 19:58, Fabiano Rosas wrote:
> >> > +static void test_multifd_postcopy_tcp_cancel(void)
> >> > +{
> >> > +postcopy_ram = true;
> >> > +test_multifd_tcp_cancel();
> >> > +postcopy_ram = false;
> >>
> >> You could pass this in, there's just one other
Hello Fabiano,
On Thu, 20 Feb 2025 at 19:06, Fabiano Rosas wrote:
> This is more or less the handshake idea. Or at least it could be
> included in that work.
>
> I have parked the handshake idea for now because I'm not seeing an
> immediate need for it and there are more pressing issues to be dea
Hello,
On Wed, 19 Feb 2025 at 22:53, Fabiano Rosas wrote:
> I don't see anything stopping postcopy_start() from being called in the
> source in relation to multifd recv threads being setup in the
> destination. So far it seems possible that the source is opening the
> preempt channel while multif
Hello Fabiano,
On Tue, 18 Feb 2025 at 19:52, Fabiano Rosas wrote:
> Do you concede that this code has a hidden assumption? Either that
> migrate_multifd() != migrate_postcopy_preempt() or that multifd channels
> must be set up before postcopy preempt channel? Because that is enough
> for us to ha
On Tue, 18 Feb 2025 at 16:47, Juraj Marcin wrote:
> > +error_report("%s: unknown channel magic: %u",
> > +__func__, channel_magic);
>
> Here, the number reported in the error will have incorrect endianness on
> a non-BE system. I think it would be be
On Mon, 17 Feb 2025 at 21:03, Fabiano Rosas wrote:
> > @@ -110,6 +129,10 @@ void migration_test_add_postcopy(MigrationTestEnv *env)
> > "/migration/postcopy/recovery/double-failures/reconnect",
> > test_postcopy_recovery_fail_reconnect);
> >
> > +migration_test_ad
On Mon, 17 Feb 2025 at 20:47, Fabiano Rosas wrote:
> I just noticed this is way more suited to be at MigrateStart instead,
> because then we can make the set_capabilities as part of migrate_start()
> and move the events setting in there as well.
>
> I also think we could just pick a default for mu
Hello Fabiano,
On Tue, 18 Feb 2025 at 03:20, Fabiano Rosas wrote:
> > -static bool migration_should_start_incoming(bool main_channel)
> > +static bool migration_has_main_and_multifd_channels(void)
> > {
...
> > +/* main channel and all multifd channels are established */
> > return true
From: Prasad Pandit
Hello,
* This series (v6) shuts down Multifd threads before starting Postcopy
migration. It helps to avoid an issue of multifd pages arriving late
at the destination during Postcopy phase and corrupting the vCPU
state. It also reorders the qtest patches and does some
1 - 100 of 249 matches
Mail list logo
