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 36EDD45D9F for ; Mon, 25 Nov 2024 04:20:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D0394027E; Mon, 25 Nov 2024 04:20:00 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id 751A0400D6; Mon, 25 Nov 2024 04:19:57 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-21271dc4084so35962035ad.2; Sun, 24 Nov 2024 19:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732504795; x=1733109595; 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=yQkOm/SoVVc88VlU+LMbsWBWfmuY1dYv2w+nOgSKbZE=; b=G2LB41bg7k1YP24SY5nFEfgJjrHE6SDMZRhrikxZxNZZJuu5AQVaqsqQrozT3jTIxM hbsgqkBbvCV1vXDj7gWjy7gJu8mXIfcTDwjhKBP2gqUJRTGQ5HJIPafBIJuuABnUwXAZ ICA4Je06hLT9qjl9rRa6KARmh9FNv1tsQf9tl+TvtPaFrZbYhy+I2ZBSYbP+xHcM/qSH WCpsUkUcuRk9z1no8x59jCm0KZ12ruUk+g4fIYo4TgZdzmTEQtrQyNbSx75I0R3cEOqD V0K78e0N1Q4xVr5km9axE5DO06RrnvU/Ow19bsby4uNlhZ56NCPszvuhfuWvAhyhzfzL 4qtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732504795; x=1733109595; 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=yQkOm/SoVVc88VlU+LMbsWBWfmuY1dYv2w+nOgSKbZE=; b=NNTEQY1YYl9TtulHFzv86ASZzSsNCmM9BANtiTy294BChL25U2e+4jzu4V9xsoYp7E KkqI9SRZ4izInoOp1shwzl8uufSZqVeEZ84XhiOSiKYH3+1O+jZKQ4Q+3A4xK9O44/1W mJJeFtJBWc/P/BMLAiRxsKXphK6tNX/UAbf6VUeZfRw8mV75KxxuJMJG/yOuMzeIISYw hFllQxmwwUgEShYiDU7QcKVtD0bibA6+ss5yXuxqLA4v2kXeyAcQBRbiEpXl3as2dg4k rvDkVA2aB+54ID7nd1YVjCj7X9qZ7ufdqgIcZkPp2SzNftRSukEtfA3X2tBLS1BrmzYS n0SA== X-Gm-Message-State: AOJu0YxsYYp7pvL4R4o4CmwjeGyu2b9Vm8GYHs/VBCw4PeYIav7XxfzG Ns+jgn8RTDHz4XW6rBnoBHJdj+ZmVQXKJTyBo/ZP32h0VnR9Q9WZiSSFkwx0Bzc= X-Gm-Gg: ASbGncu+L6xeIJF8/qqM9OHwCtTFV4aa8Mm3d9SrfhkPbe5TRT5GNx+NhaUHV/GS3kA EUHf2oZVHW2DfH7S+N1GSeWAYnJwO6v4jAu/Q7fKQo2KJLANEkKrRuV4n8eFUOX5M+itUOlJTSj 2b4Es+scvY1A6XkxpyQvaxgZKtq6pEe337hJFBes9KRYL5DwVSoO5Fr2CY1Zo8xeEC9MwW8RU1r NaDdhiBxtsRWuRlPrBodiqhIJj1xQ4JFW+KU8EO+7qxm0nbB/8tDWJWnqSYNt16gRqdxnknEkI= X-Google-Smtp-Source: AGHT+IFdZJuQ4T99ufWRxcfTPeWshmSc8XU7AsF9EsJjZjKeQexrdXJ2dQKUo39x6wYlsrQrzXO5kw== X-Received: by 2002:a17:902:f690:b0:20c:a19b:8ddd with SMTP id d9443c01a7336-2129f69f4e5mr124867875ad.51.1732504794471; Sun, 24 Nov 2024 19:19:54 -0800 (PST) Received: from jeffzhao-1.NEBULA-MATRIX.COM ([223.65.28.15]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2129dc1746fsm54199935ad.219.2024.11.24.19.19.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Nov 2024 19:19:54 -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:19:46 +0800 Message-Id: <20241125031946.2102069-1-zhao305149619@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org From: "Jianping.zhao" 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") Cc: stable@dpdk.org Cc: Maxime Coquelin Cc: Chenbo Xia 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