patch 'vhost: clear ring addresses when getting vring base' has been queued to stable release 24.11.2

[Kevin Traynor]

Hi,

FYI, your patch has been queued to stable release 24.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 02/17/25. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/f57032f4378a07608aa907883fd9a762ade4b962

Thanks.

Kevin

---
>From f57032f4378a07608aa907883fd9a762ade4b962 Mon Sep 17 00:00:00 2001
From: Jianping Zhao <zhao305149619 at gmail.com>
Date: Wed, 27 Nov 2024 10:03:49 +0800
Subject: [PATCH] vhost: clear ring addresses when getting vring base

[ upstream commit 1846fe767f00a9d0dade333e7838f81e6721b694 ]

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 <zhao305149619 at gmail.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin at redhat.com>
---
 .mailmap               | 1 +
 lib/vhost/vhost_user.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 818798273f..1a1744df4d 100644
--- a/.mailmap
+++ b/.mailmap
@@ -674,4 +674,5 @@ Jianfeng Tan <jianfeng.tan at intel.com>
 Jiang Yu <yux.jiang at intel.com>
 Jiangu Zhao <zhaojg at arraynetworks.com.cn>
+Jianping Zhao <zhao305149619 at gmail.com>
 Jianwei Ma <jianwei.ma at intel.com>
 Jianwei Mei <jianweix.mei at intel.com>
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
@@ -2278,4 +2278,5 @@ 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);
 
-- 
2.48.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-02-12 17:29:34.969644619 +0000
+++ 0003-vhost-clear-ring-addresses-when-getting-vring-base.patch	2025-02-12 17:29:34.118944545 +0000
@@ -1 +1 @@
-From 1846fe767f00a9d0dade333e7838f81e6721b694 Mon Sep 17 00:00:00 2001
+From f57032f4378a07608aa907883fd9a762ade4b962 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit 1846fe767f00a9d0dade333e7838f81e6721b694 ]
+
@@ -36 +37,0 @@
-Cc: stable at dpdk.org
@@ -46 +47 @@
-index b90ff0444c..cc1ffe1ad9 100644
+index 818798273f..1a1744df4d 100644
@@ -49 +50 @@
-@@ -675,4 +675,5 @@ Jianfeng Tan <jianfeng.tan at intel.com>
+@@ -674,4 +674,5 @@ Jianfeng Tan <jianfeng.tan at intel.com>