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 83E1245D76; Wed, 27 Nov 2024 03:04:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4BCFE4027A; Wed, 27 Nov 2024 03:04:25 +0100 (CET) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id 348F24026C for ; Wed, 27 Nov 2024 03:04:23 +0100 (CET) Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-21278f3d547so48348145ad.1 for ; Tue, 26 Nov 2024 18:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732673062; x=1733277862; 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=Nf+5K5sNIkRS/HyixsZ/0FI883YD1g5A8y59o5vYzQFTRa4vVFGeZmByp0Dz5xrPko F6q3CKxBGrKa0WdxiantWISaAA7nBEZmrBDSpwdN2JapDk0y30QjGyqzi7uecA22C73c 6GaWBYx2FE35BebTMsUQ912voisbOIDt1JrqdoCNBZQUehrnN5y3hVjCau0FR62tw06L /tmT1Q79BMyVLnpot3pZxuqDGVX9U07/zZmxSBXN9CDYm137sgqL0n5PX5+bl2nCcV5K v4knFcUqjgWpc4KgwNf4kWqJ+k3/3tZsqg/Ru9as6rWSc7GtUJzyZcD9LZGZtV33XIyg pmJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732673062; x=1733277862; 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=qIYzdbZaGaDBnn6y4ES/Fiyxs/yqQkunpOAPMX5ncDNot9KgKKnQTFfsTJQ9vIAOyg Roslgj1MQIJeJL/+0w88KfTyflz/Eq8vhkdFb/Ybbysn97YMgrpapHfLHLSDYZHptzHH JiHFoeJP2ikOAtEIw+otIIDqF7E/dyiUZ91FOvMGbpOBJ9vCCoM0hQrGluG5+8LEqwZn TG6ojirevc/4uD3KIkf3ET6/NxIc6j7HUCzlIvEgkNgaMDoDLXUtb2R+BsLLQW9m3zeV VUYLqWedB+wOJ2fukOBqUyKhwM3pmXEoq60pYtQ7kp1FXzwkGr+zHMm/lLfJhM1sLTTS 1AEA== X-Gm-Message-State: AOJu0YxL0/wj0TOkWyjagAqMBJtAnpPG6zGhlZaCWZE+1se5uVu15gkf JQYSrC9nd8mQLZpUbhgkPL6r40BR5RqReWZXc9p++Wk6uy+gq6WF X-Gm-Gg: ASbGncuYSv8hpCr6Kl0K4AvjC76uxlyOVj/uSuIJYnttfJU1e6GpSjC8zQlUW9wYhBH HFTDvvhKcAMOLAheTMa/AOTg0BGRzdqiNHlEjQ9gxe7Jw25JcH2jIBKZ2hvkYXJz/6Y/W5TOVW1 yBG2vFeK08H3UJLV45MKWaYqnjIGX8BkEZxFe3+Ld5Jkqplbclnm/1leQLXw+fKOKA0ooj0L94H kGgVI6wjCLk2UWPdNlCID6xk1uByUx2M487gyWl6ke2Rkhq1rKpoasLa2O52I6iLlZGQakEduaD X-Google-Smtp-Source: AGHT+IGORfgEwEXGWNzfj5gmgHC9yA4RJtBZ4rRw4m1a8cWu2NOSwAzAYeFrcv5RaF36qoJJxPoqvA== X-Received: by 2002:a17:902:d4c4:b0:212:f64:8d9f with SMTP id d9443c01a7336-21501856d3bmr19922005ad.32.1732673062058; Tue, 26 Nov 2024 18:04:22 -0800 (PST) Received: from jeffzhao-1.NEBULA-MATRIX.COM ([117.62.134.42]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2129dba269csm91747105ad.99.2024.11.26.18.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2024 18:04:21 -0800 (PST) From: Jianping Zhao To: maxime.coquelin@redhat.com Cc: dev@dpdk.org, Jianping Zhao Subject: [PATCH v4] vhost/user: clear ring addresses when getting vring base Date: Wed, 27 Nov 2024 10:03:49 +0800 Message-Id: <20241127020349.3968025-1-zhao305149619@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241125034550.2112273-1-zhao305149619@gmail.com> References: <20241125034550.2112273-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