From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2789F45D9E; Mon, 25 Nov 2024 04:42:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F020F4026B; Mon, 25 Nov 2024 04:42:49 +0100 (CET) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id 944964021F; Mon, 25 Nov 2024 04:42:48 +0100 (CET) Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2124a86f4cbso34900955ad.3; Sun, 24 Nov 2024 19:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732506167; x=1733110967; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=C96LIAsHELAvsccTEKeDUvGfGsWfFkeB7zRDT5IX25c=; b=G9URs940Fp1Evq4TT1H9MA50rNSaebIeNG9Ubue/7Wi4ayzd/H4rPcLU+wgO+SGZ7S YrjbY7GvJ+yFqFNejOsRSKhs9FDL4HQgEkCrdGJVTBCjCUXMm4kErnYQ0yRakRd2Mj4J CDrNrmZppgaYXppM5sTry7XcEY0dqhF2RbwwjlFDsjIW4eIWMX2cgX2f0K8BryOT7Qr/ up5jKtyTF4M8P7fjBDAgLCqu8hWK55Hj51M8oIquArhtsJJ7TrQ0rrYVxa7NZFSsPyy3 j/aEzNJEsidvWoBmHuwYqU7MhzJ+bp4Ah0EWkimHAjCGmZQP/godk43JjkjJ/iXyJwxe P7NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732506167; x=1733110967; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C96LIAsHELAvsccTEKeDUvGfGsWfFkeB7zRDT5IX25c=; b=CvqOBJg4aVdemJyZjXxen/afQNcgfGGv+y+4JwaAz/CZ1kzEa4xoXUHEMyVvro0kKD sBpLvKGzx70Z+jRQbSxI903vxYQivQySBH298wwUTzy4yRTvgMkZ4g0yy1aJk8LygPDF UbssxYwEW4yBObswxdMvpNrldku7XHYpr+C1G6OLCihLlfapeaMGpPs+LArROFH0uaS/ gQWkcdU65R6+p6rUBMBR6/qXu+AyuZE1L3qgVyFUNq7xEbhO9pRkNUOo78iJkf5T6HXv In3Kw0kRXW09D1GMs82X/kyiAaNAByocatFFSG2xvzlzpDXTtFmdBqijGv6KO1/SIMTA DYXQ== X-Gm-Message-State: AOJu0YyxnzMLqe0Kf4uw4rNOSw+R/+KdUW2mzNqgKSAucrUTCNl314wN uCvm3vBSoLTth6+MesjJydAJu8bWmkTGzuUFHvwmeuDqJ3JcyJ3Sc/uoUE0wgOE= X-Gm-Gg: ASbGncs5/7xN5AO295q52lYdpyjXqUDKPCW5WMj0PN40/DXAjIueetzi1E9AXM3p1jL oiM0LLD0XOzUr1o8VB11gZn9Bs462mCgNeBW6mqsY2mUKmbcfYQ038dyzKjs/Lx7jLPtJqdRNyt rDrlPBsdREecWuqnkiYXJ8lLaGeZQ27CFQ1IFyRNnHRx0n0s3L+xhGGYNBlUs0isLV78toFJ8yR 7GEqPvlnRBafKaKJlFhdTKpcw7zMXAkZLVVwycbxGqw24ENhfltsgHCu/khuYgoCaS+en9PAQM= X-Google-Smtp-Source: AGHT+IHKF/TkTYsQeELv9bhcquiX7JXad15/IRyPd4sb9jl3rt7KdPdDW/zATtldqUqaQQwdYNN4dA== X-Received: by 2002:a17:902:f548:b0:211:f6e4:d68f with SMTP id d9443c01a7336-2129f7302d2mr150894555ad.6.1732506167528; Sun, 24 Nov 2024 19:42:47 -0800 (PST) Received: from jeffzhao-1.NEBULA-MATRIX.COM ([223.65.28.15]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2129dba1b40sm54214945ad.87.2024.11.24.19.42.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Nov 2024 19:42:47 -0800 (PST) From: Jianping Zhao To: dev@dpdk.org Cc: stable@dpdk.org, maxime.coquelin@redhat.com, chenbo.xia@intel.com, Jianping Zhao Subject: [PATCH v2] vhost/user: clear ring addresses when getting vring base Date: Mon, 25 Nov 2024 11:42:35 +0800 Message-Id: <20241125034235.2110875-1-zhao305149619@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Clear ring addresses during vring base retrieval to handle guest reboot scenarios correctly. This is particularly important for vdpa-blk devices where the following issue occurs: When a guest OS with vdpa-blk device reboots, during UEFI stage, only one vring is actually used and configured. However, QEMU still sends enable messages for all configured queues. The remaining queues retain their addresses from before reboot, which reference invalid memory mappings in the rebooted guest. The issue manifests in vq_is_ready(): static bool vq_is_ready(struct virtio_net *dev, struct vhost_virtqueue *vq) { /* Only checks pointer validity, not address freshness */ rings_ok = vq->desc && vq->avail && vq->used; ... } vq_is_ready() incorrectly considers these queues as ready because it only checks if desc/avail/used pointers are non-NULL, but cannot detect that these addresses are stale from the previous boot. Clear the ring addresses in vhost_user_get_vring_base() to force the guest driver to reconfigure them before use. This ensures that vq_is_ready() will return false for queues with stale addresses until they are properly reconfigured by the guest driver. Fixes: 3ea7052f4b1b ("vhost: postpone rings addresses translation") Signed-off-by: Jianping Zhao --- lib/vhost/vhost_user.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index 6d92ad904e..52d8078d7c 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -2277,6 +2277,7 @@ vhost_user_get_vring_base(struct virtio_net **pdev, rte_rwlock_write_lock(&vq->access_lock); vring_invalidate(dev, vq); + memset(&vq->ring_addrs, 0, sizeof(struct vhost_vring_addr)); rte_rwlock_write_unlock(&vq->access_lock); return RTE_VHOST_MSG_RESULT_REPLY; -- 2.34.1