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 9EB0345D9E; Mon, 25 Nov 2024 04:28:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6683D4026B; Mon, 25 Nov 2024 04:28:25 +0100 (CET) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by mails.dpdk.org (Postfix) with ESMTP id 6F35F4021F; Mon, 25 Nov 2024 04:28:23 +0100 (CET) Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-7f8b37edeb7so3389622a12.0; Sun, 24 Nov 2024 19:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732505302; x=1733110102; 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=CqOtNJJzWQyJRcSO9tSBjxcAb3oxcNWYRgsd2TqIekc=; b=cVrmFg6uwczfBNqcmEG0D6LMB54rSX3G4GUY7PdH5P0UpT4DGTznGnqRjmS2u+6dJc flyGO+BhUiLL7VLV4aabmicJZ5o4/CCTNG6BK7vhE5w6VKRVHchkWEf6v+vSLIa7fPX9 iwY4YIGk+XUrnmrGL0O/C+/fEY4kPVld5c2yw+rszM93jfI4n9IwfnImovXJMZ2R50Au 3Kok0zsAU+0ntVucuASJKhjZ7VaHPJ1OvnhpgDhZTzY8CA3PkId9FiS/iZmhHC68YIgc 6neh5bUEPhAxmfHKiScWhPAitF4YeoT5F5AbYdyLHJP/IbyAw20nVwvuQW8Ipx60NuGb Q1SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732505302; x=1733110102; 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=CqOtNJJzWQyJRcSO9tSBjxcAb3oxcNWYRgsd2TqIekc=; b=v+iAxje5o24x/O9GB2KfiPIiIF4DbPDqQr60z9xCiQKWfil+fs3oREovHkZRdNIgTI dxWYzWr6im1qU5N51sqmuEFTrXhxArW56F3YMUVdQ0uiLh4KEfUqgJxa/q/kR4sY8uFD xusc/SN0syMLFkbHOnjo1clZBQhEILQsKimvMNgJxE3MaFuIdkXTw3b1CNbqa57oA0aB 7QHFN7eDYfPNRb2/kdhKf03k7VI1VnrB1vKSQs3aqAKiZzBV6z8dbWYXpHG6jgrL4JLG y6+y+jTXxrAimeQHXXapjHP2MM80K5Gv3B6bi3yukKgovp8jSxRxg4lxLltiykWItpvV QuXQ== X-Gm-Message-State: AOJu0YyZ2ZwDgPd4vTsXEuD8s6j5eHRBOj8nzxpRH/DJm9zpSoa+XKHz ymBHjt2Kqu0dm3OF0b6U54T2agyOE4Ww40qa9chyEphsWtT4shHfN52E6EdRGcA= X-Gm-Gg: ASbGncud6Rr56MeVqi9Ym1VAiII6H/QjFQWJZf3lERFObq3UiOKwV3gWkRF0Zh4I7ON eWSqV6nB+LM7lJ2clZsbRW6PNloHH3eeVCxosuTQKbjUkseeTLisWzxnV7KOX0RHGvkZ7DZ/71r NP27Ri+YcP+1EhDw4iFJnoU8vLCpCDe09UZXq0SnPPRZAEf4pmjwNOri80cGTYbh9gD0OInaAA1 DbSzCzJoJ0JCaqbTISkIrRUCPSC1avAyWUnfUD0B8iy+8JX4Qg+OfGkyHaPHt/JUEkRDbKAzmA= X-Google-Smtp-Source: AGHT+IHQLcr4OxNDRoRCLg0TJ4Lt89tSsLGETr4IjkBy745pFySz4vdEkOcZbZD3GbOPZdG89xxQLw== X-Received: by 2002:a05:6a20:3d8d:b0:1db:a33e:2c6 with SMTP id adf61e73a8af0-1e09e420a72mr17712372637.18.1732505302312; Sun, 24 Nov 2024 19:28:22 -0800 (PST) Received: from jeffzhao-1.NEBULA-MATRIX.COM ([223.65.28.15]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-724e2896396sm5002765b3a.167.2024.11.24.19.28.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Nov 2024 19:28:21 -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] vhost: clear ring addresses when getting vring base Date: Mon, 25 Nov 2024 11:27:59 +0800 Message-Id: <20241125032759.2105124-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