[PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[Maciej S. Szmigiero]

From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>

If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
flag is forced into all multifd channel write calls via p->write_flags
that was setup in multifd_nocomp_send_setup().

However, device state packets aren't compatible with zerocopy - the data
buffer isn't getting kept pinned until multifd channel flush.

Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
send thread if the data being sent is device state.

Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send side")
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
---
 migration/multifd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/migration/multifd.c b/migration/multifd.c
index ec108af6245a..843c7740a4ec 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -690,6 +690,7 @@ static void *multifd_send_thread(void *opaque)
         if (qatomic_load_acquire(&p->pending_job)) {
             bool is_device_state = multifd_payload_device_state(p->data);
             size_t total_size;
+            int write_flags_masked = 0;
 
             p->flags = 0;
             p->iovs_num = 0;
@@ -697,6 +698,9 @@ static void *multifd_send_thread(void *opaque)
 
             if (is_device_state) {
                 multifd_device_state_send_prepare(p);
+
+                /* Device state packets cannot be sent via zerocopy */
+                write_flags_masked |= QIO_CHANNEL_WRITE_FLAG_ZERO_COPY;
             } else {
                 ret = multifd_send_state->ops->send_prepare(p, &local_err);
                 if (ret != 0) {
@@ -718,7 +722,8 @@ static void *multifd_send_thread(void *opaque)
                                               &p->data->u.ram, &local_err);
             } else {
                 ret = qio_channel_writev_full_all(p->c, p->iov, p->iovs_num,
-                                                  NULL, 0, p->write_flags,
+                                                  NULL, 0,
+                                                  p->write_flags & ~write_flags_masked,
                                                   &local_err);
             }
 

Re: [PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[Fabiano Rosas]

"Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes:

> From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
>
> If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
> flag is forced into all multifd channel write calls via p->write_flags
> that was setup in multifd_nocomp_send_setup().
>
> However, device state packets aren't compatible with zerocopy - the data
> buffer isn't getting kept pinned until multifd channel flush.
>
> Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
> send thread if the data being sent is device state.
>
> Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send side")
> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>

Reviewed-by: Fabiano Rosas <farosas@suse.de>

Re: [PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[Peter Xu]

On Fri, May 16, 2025 at 03:53:03PM +0200, Maciej S. Szmigiero wrote:
> From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
> 
> If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
> flag is forced into all multifd channel write calls via p->write_flags
> that was setup in multifd_nocomp_send_setup().
> 
> However, device state packets aren't compatible with zerocopy - the data
> buffer isn't getting kept pinned until multifd channel flush.
> 
> Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
> send thread if the data being sent is device state.
> 
> Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send side")
> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>

queued, thanks.

-- 
Peter Xu

Re: [PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[Michael Tokarev]

On 16.05.2025 16:53, Maciej S. Szmigiero wrote:
> From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
> 
> If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
> flag is forced into all multifd channel write calls via p->write_flags
> that was setup in multifd_nocomp_send_setup().
> 
> However, device state packets aren't compatible with zerocopy - the data
> buffer isn't getting kept pinned until multifd channel flush.
> 
> Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
> send thread if the data being sent is device state.
> 
> Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send side")
> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>

Is this qemu-stable material (for 10.0)?

I'm picking it up for 10.0 branch, please let me know if I shouldn't.

Thanks,

/mjt

Re: [PATCH] migration/multifd: Don't send device state packets with zerocopy flag

[Peter Xu]

On Thu, May 22, 2025 at 11:12:22PM +0300, Michael Tokarev wrote:
> On 16.05.2025 16:53, Maciej S. Szmigiero wrote:
> > From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
> > 
> > If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
> > flag is forced into all multifd channel write calls via p->write_flags
> > that was setup in multifd_nocomp_send_setup().
> > 
> > However, device state packets aren't compatible with zerocopy - the data
> > buffer isn't getting kept pinned until multifd channel flush.
> > 
> > Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
> > send thread if the data being sent is device state.
> > 
> > Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send side")
> > Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
> 
> Is this qemu-stable material (for 10.0)?
> 
> I'm picking it up for 10.0 branch, please let me know if I shouldn't.

Yes please, for two migration patches in the lastest pull.  I forgot to add
Cc: for stable.  I'll try to remember again, thanks.

-- 
Peter Xu