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 D01B345D9E; Mon, 25 Nov 2024 04:45:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF33C4026B; Mon, 25 Nov 2024 04:45:59 +0100 (CET) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by mails.dpdk.org (Postfix) with ESMTP id 38C094021F; Mon, 25 Nov 2024 04:45:58 +0100 (CET) Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-720c2db824eso3966205b3a.0; Sun, 24 Nov 2024 19:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732506357; x=1733111157; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=C96LIAsHELAvsccTEKeDUvGfGsWfFkeB7zRDT5IX25c=; b=PMPN8drKQf2vjmBLaZtSY9L9++ez3oXXuJAU2Iw8As0eOaCWDN5+s3QIPj8kWUMh6W uAbPdJrpuD0LXFHr21Mg50Lkiqsfjlf96/BNp/e2yJ6iK4cJuRyRx33voL0Om05IcCdp DWO6KTrkTCHk3e9I+guUcpsLJ/RIHPS+YrDvh3C0K8QazC9mHfukEFR0QrXJq/W2fUiA r6uSKQVORwngC5RaeC+73vZL3CiZroGbPjwC744OYpO3/rrwAyCasu9WZ2Tbh62bZ6O5 X1xaE0C3cxiADymh1wPAsGme4qtqc5ve6BTn3yuGs+91nzF/kaGkL8CgL6JUyphiPAQb l+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732506357; x=1733111157; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C96LIAsHELAvsccTEKeDUvGfGsWfFkeB7zRDT5IX25c=; b=VgKxzhi7g+2gLcB82M2lyOjRhCJjje8NXd7e6g4hgF1fDWEfLW1heH08gUx3VSBwDH ntSB+NT+kIzr0ryM5BEGkwZmgEKHQUInkMsY8co5xlQY2e9Qo83kvqM+57wDLgIL0FoX nkaALrJDf4FcJYnv4zC5f9zb4+rGYL+yU9LhLN0Iap5HEHZ5iXJK3cx9IBOPbED7kGy1 8CD++ae4Bijk4tHEPmX/aFkxbwqqfWd7ffpcBH/x3LhQp+mr7K66a5RtoO4o726hnkAA lAL4Bnorz69R3/WBQOv5pfCT2Y8MBMEZNf4GHpsSTTCYT2V4Y4BB060X48zm72qMdTkW q3JA== X-Gm-Message-State: AOJu0Yzg0ShVpLKhXnm9h4CFfXUdY/yLHfxsGVlR5msp8Q5Uf8iW2rOu gkhN4Z89iapzjZIeUfdXRyct2PIeFCyZSoJmB05kC//zvXgft98YpJXuaPQN5j8= X-Gm-Gg: ASbGncvVhyDsU0ZcYw6Te5LMlCWJDqbV940jDGIWCtaAc4CyFUXJnIep5zN5/+AmAY6 0k+qc116BbIQC7ZMvBW0udQAwV+5KIis4K6OH6WCZKGYRgn1duFqSS5DKDZz+Njp4FH0fJaxi6Q K9olT5d1f+G8AFOoVkk27Ar102FUB1/vCgvfsZoim5UrtEs9Eo1XBfb1zThJKyBvl3IixBYfceq e0Pvw6Kp5PuO+R6EwC6Ldiq8pyZDiGX9HQllFA0xjnS9RavO8P93sc1C5UN7UC08Gd+S/N+kpQ= X-Google-Smtp-Source: AGHT+IH8TGi4XLacEo2RqI37ZpqWxmreCwRwtML2FvykE71iCV5DHdLvTFh1QHJzgQRAFz2bo/prIQ== X-Received: by 2002:a05:6a00:230c:b0:71e:7846:8463 with SMTP id d2e1a72fcca58-724df6df471mr17067575b3a.19.1732506356922; Sun, 24 Nov 2024 19:45:56 -0800 (PST) Received: from jeffzhao-1.NEBULA-MATRIX.COM ([223.65.28.15]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-724de55503bsm5504881b3a.142.2024.11.24.19.45.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Nov 2024 19:45:56 -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 v3] vhost/user: clear ring addresses when getting vring base Date: Mon, 25 Nov 2024 11:45:50 +0800 Message-Id: <20241125034550.2112273-1-zhao305149619@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241125034235.2110875-1-zhao305149619@gmail.com> References: <20241125034235.2110875-1-zhao305149619@gmail.com> 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