[{"id":3673166,"web_url":"http://patchwork.ozlabs.org/comment/3673166/","msgid":"<70bdb32a-3a9c-4674-980d-1f94612c62ea@yandex-team.ru>","list_archive_url":null,"date":"2026-04-03T15:10:18","subject":"Re: [PATCH] vhost-user: fix wrong index for postcopy_client_bases","submitter":{"id":84116,"url":"http://patchwork.ozlabs.org/api/people/84116/","name":"Vladimir Sementsov-Ogievskiy","email":"vsementsov@yandex-team.ru"},"content":"On 03.04.26 12:34, Vladimir Sementsov-Ogievskiy wrote:\n> u->postcopy_client_bases[i] corresponds to dev->mem->regions[i], not\n> to u->shadow_regions[i]. So we should use j-index, following indexation\n> of dev->mem->regions.\n> \n> Fixes: f1aeb14b0809e313c7424 \"Transmit vhost-user memory regions individually\"\n> Signed-off-by: Vladimir Sementsov-Ogievskiy \n> ---\n> \n> Hi all!\n> \n> Honestly, I don't follow the logic of vhost-user postcopy, but I can't\n> believe, that the same array should be used in different indexing\n> semantics.\n> \n> hw/virtio/vhost-user.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c\n> index a8907cca74e..91de08a5128 100644\n> --- a/hw/virtio/vhost-user.c\n> +++ b/hw/virtio/vhost-user.c\n> @@ -602,7 +602,7 @@ static void scrub_shadow_regions(struct vhost_dev *dev,\n> if (fd > 0) {\n> u->region_rb_offset[j] = offset;\n> u->region_rb[j] = mr->ram_block;\n> - shadow_pcb[j] = u->postcopy_client_bases[i];\n> + shadow_pcb[j] = u->postcopy_client_bases[j];\n> } else {\n> u->region_rb_offset[j] = 0;\n> u->region_rb[j] = NULL;\n\n\nHmm, now I think, that postcopy + CONFIGURE_MEM_SLOTS is totally broken\nboth in protocol and in the code.\n\nLook:\n\nfor VHOST_USER_SET_MEM_TABLE we have not in the spec:\n\n.. Note::\n ``NEED_REPLY_MASK`` is not set in this case. QEMU will then\n reply back to the list of mappings with an empty\n ``VHOST_USER_SET_MEM_TABLE`` as an acknowledgement; only upon\n reception of this message may the guest start accessing the memory\n and generating faults.\n\n\nand in code we do in vhost_user_set_mem_table_postcopy():\n\n msg.hdr.size = sizeof(msg.payload.u64);\n msg.payload.u64 = 0; /* OK */\n ret = vhost_user_write(dev, &msg, NULL, 0);\n if (ret < 0) {\n return ret;\n }\n\nNote, that msg.hdr.request is set to VHOST_USER_SET_MEM_TABLE by\nvhost_user_fill_set_mem_table_msg() call.\n\n\n\nBut when CONFIGURE_MEM_SLOTS is negotiated we don't use VHOST_USER_SET_MEM_TABLE\nmessage, instead we use VHOST_USER_REM_MEM_REG and VHOST_USER_ADD_MEM_REG.\n\nfor VHOST_USER_REM_MEM_REG we have nothing about postcopy in documentation,\nand for VHOST_USER_ADD_MEM_REG we have only:\n\n In postcopy mode (see ``VHOST_USER_POSTCOPY_LISTEN``), the back-end\n replies with the bases of the memory mapped region to the front-end.\n For further details on postcopy, see ``VHOST_USER_SET_MEM_TABLE``.\n They apply to ``VHOST_USER_ADD_MEM_REG`` accordingly.\n\nhow should it work about \"an acknowledgement\"? Should QEMU send\nan empty VHOST_USER_SET_MEM_TABLE ? And when?\n\n\nLet's see what we have in code:\n\nvhost_user_add_remove_regions() {\n\n if (nr_rem_reg) { send_remove_regions() }\n\n if (nr_add_reg) { send_add_regions() }\n\n ... and for postcopy:\n\n msg->hdr.size = sizeof(msg->payload.u64);\n msg->payload.u64 = 0; /* OK */\n\n ret = vhost_user_write(dev, msg, NULL, 0);\n if (ret < 0) {\n return ret;\n }\n\n\nNote that:\n\n1. We send only one acknowledgement, after sending several (or zero)\n ADD/REM requests.\n\n2. We send an acknowledgement with request set to either VHOST_USER_ADD_MEM_REG,\n or VHOST_USER_REM_MEM_REG, or zero (if bot nr_rem_reg and nr_add_reg are zero).\n\n\nI think, it far far away from documentation. And it can't be simply \"fixed\". If we\nneed postcopy for CONFIGURE_MEM_SLOTS case, the protocol extension to support it\nshould first be invented.\n\n\nI think, it would be correct to abandon using postcopy together with CONFIGURE_MEM_SLOTS\nfor now, and document that behavior of server is actually unpredictable if use postcopy\ncommands together with CONFIGURE_MEM_SLOTS negotiated.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=yandex-team.ru header.i=@yandex-team.ru\n header.a=rsa-sha256 header.s=default header.b=z00OG16W;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net;\n dkim=pass header.i=@yandex-team.ru"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fnMcl35KCz1xtJ\n\tfor ; Sat, 04 Apr 2026 02:11:19 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1w8gAI-000899-H0; Fri, 03 Apr 2026 11:10:30 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w8gAF-00086Z-4Z\n for qemu-devel@nongnu.org; Fri, 03 Apr 2026 11:10:27 -0400","from forwardcorp1a.mail.yandex.net\n ([2a02:6b8:c0e:500:1:45:d181:df01])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1w8gAC-0000Yl-N5\n for qemu-devel@nongnu.org; Fri, 03 Apr 2026 11:10:26 -0400","from mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net\n (mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net\n [IPv6:2a02:6b8:c0c:2008:0:640:480d:0])\n by forwardcorp1a.mail.yandex.net (Yandex) with ESMTPS id 4ED0EC01EF;\n Fri, 03 Apr 2026 18:10:19 +0300 (MSK)","from [IPV6:2a02:6bf:8080:d4c::1:2b] (unknown\n [2a02:6bf:8080:d4c::1:2b])\n by mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (smtpcorp/Yandex) with\n ESMTPSA id IAfmpX0K5mI0-fozubs6z; Fri, 03 Apr 2026 18:10:18 +0300"],"X-Yandex-Fwd":"1","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru;\n s=default; t=1775229018;\n bh=Dszo96Rqq7VC7o7Rk/jNRIX+o5bL7rFVMwyU17OdRWc=;\n h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID;\n b=z00OG16WV+duzK27Jg5SzGCXbgUBGGfia81MCBSRgUL88UAeKQZJiG50WYwaK1NpH\n MH5+0LzP3XpoFvih2PA8/wKb4mafVihrvNZlg/+9YH+zerYb5ipYcFXnsjEvFHmxDt\n ZBUGS4/UCjjkzR0+koqqBZLh1lLOM/KdLbrSe25Q=","Message-ID":"<70bdb32a-3a9c-4674-980d-1f94612c62ea@yandex-team.ru>","Date":"Fri, 3 Apr 2026 18:10:18 +0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] vhost-user: fix wrong index for postcopy_client_bases","To":"mst@redhat.com","Cc":"sgarzare@redhat.com, raphael.norwitz@nutanix.com,\n swapnil.ingle@nutanix.com, peter.turschm@nutanix.com, cui@nutanix.com,\n marcandre.lureau@redhat.com, qemu-devel@nongnu.org","References":"<20260403093411.1431802-1-vsementsov@yandex-team.ru>","Content-Language":"en-US","From":"Vladimir Sementsov-Ogievskiy ","In-Reply-To":"<20260403093411.1431802-1-vsementsov@yandex-team.ru>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","Received-SPF":"pass client-ip=2a02:6b8:c0e:500:1:45:d181:df01;\n envelope-from=vsementsov@yandex-team.ru; helo=forwardcorp1a.mail.yandex.net","X-Spam_score_int":"-27","X-Spam_score":"-2.8","X-Spam_bar":"--","X-Spam_report":"(-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]