From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1A42331ED1 for ; Tue, 4 Aug 2026 04:19:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785817150; cv=none; b=NzHYypS9VI1uqx7dZNc6mZRw9UlOCfA4siILaDihEJT1vtrK7k7tq9mENNv3YkNvmL6Z4qnL0BMBgSKK0GRrygQsGAmhClRxh4mG0JWTl0WowjytFw5F9ndm34gN8iBGqqfwbPgCCkYZEFKiadKVzouNKXwEGmXYv8Ne2IfTK0o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785817150; c=relaxed/simple; bh=Ehv6ZpiwwQTVEJVQYx8VsZm6ew9x8gEVlTBOFfynDtc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Qhf1aSB8Ic6Dr/mr51tUKW15IiKaoVEoHBRbkSxGtD/fJmcb3YmocMJE3tXus6iWRmb9GC3pnz4n1OfZtQiLIDevhokKVSRe0RktmFK+iG+Uj7gaLzLKTij4Dtv5EV2+/cOyv42iPYCp/PdrVne6I387MQmB+XE6AqC5i6jdWrk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NyCoSyJ7; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NyCoSyJ7" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2caf228a910so30461155ad.2 for ; Mon, 03 Aug 2026 21:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785817149; x=1786421949; darn=vger.kernel.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:content-type; bh=osDb3QU8E2plb1DNFxL1j8vSW/KoqghbaQXI4jZIOlw=; b=NyCoSyJ7A1cS8LcT42kMexYSmBGKJKViYvMxH9F558j+d+BxT0pVb3LxhNZVCXM8Cf 0Wxi59ZxkULRNpFCoiP7xU38szatzlnWKgUrtKuWD55xO9ZNIiZhlbqtBsFGIB5Gv/Zy IP59rwtYasQfhNaGnjavyLwnVLKKYM0TzwkxPWMMXuhiAZ7C+pVYm03kKM/h8MmGQ2Rb bhx783aH0CioC8cjrqjug8xauzO6nXfYAA16hDgtIFVaBZEZ/XkM3Ds9+yQinjxadz7T zsSOKiB9r6Az+XMr4qPaZUzkKDnyZACgL7uj5MRFfIlrkuUvSURKEht68z9uydoL8ua8 sTCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785817149; x=1786421949; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=osDb3QU8E2plb1DNFxL1j8vSW/KoqghbaQXI4jZIOlw=; b=f0Uz6wgsE0LPpcQhLu+Z76Z/0EZMJU8jArswY1gw7m77sse9QYrmKwvI5gjPZweOmw ARPKRu/pt3TDxoo80gix++e2GQ8nz43Na49oZF45XNdI0J7LdBCkegq5ny0giHqi6EAb u+U4VkCqqDxRJKrQxU+2Q+8+d3SlCNj3s9QC3uuddo0ufaA6/MdQel+5lRt+gRn7FvDz Qtlvj4YZXp6VBuljEBnarTyP7oHG3Wwhbipu6cXpIBTm+CF3cgaPdM4BJ6gWKYlsaVzN 0yVbYyZ6KnlgJ87sROARwHytQ1yPZ+bCg9g3pDVG+ZN0QZVcpMfR0H8lVVyHzCxFNf+/ cPyg== X-Forwarded-Encrypted: i=1; AHgh+RqfGp3mmTLJeOA1vHF69QJVJOAo+dTzH37XmWbqu15KAYOgU8JuHGj20nTtvepsU2U3WTGN3bc6U/E9LWc=@vger.kernel.org X-Gm-Message-State: AOJu0Yx//UyCpQPY79igmgrPYtcflUGEdUAnX7IJTRwy7kIBqKgtTJDy gJ7hss3ypc6X0FhUVfWqqOFsvmncNX6bgVyRscvU5UYMgrxkRTx0oCMq X-Gm-Gg: AR+sD1307mS8bhhz8zwNiv85+mwLmnlv5BaZ54nt3VuoAy447jV5TQE0I8ca7F8W99I mFRtj8jiYKbnpingVvjm0hE3WQEy4Wx6myYXrYkXFY2XiwrOVPllnNKV6qjOiITtWFyvBtDYK8N vU2deeF0N6HhB72Y/6aPFfTnguPd7C3oEFKdDJ/vejoEZ2ag1OdGZb/mgN2nBR2mVNL310WEFD0 BCVHVTFfB91alT1IyySj4MAJHtqKPpOHassugwv1vQoVAQvoJBgZLeo/oOW55zPgyUHNI2DUhJq 5Uhl/TB3zD4cxrdmdDWNVzrlcwa0t8JN49qYCxeg9i7DX+Jc804PelEk7cgZoRaVOv24TQXMh/U 1It/+4I3/ryAacoAbwPGIgfmiNg9/p0VDrbzGqxCMhP0Kg9r0EiJk+p7xkOrxPiQk7bq9/hspJs ZX73QcpDRRvzolUJ0JA6LvSwn5MrkIHVau1M6UwgWtJ8QN5LUw7Abm3+8eQtsj3hM= X-Received: by 2002:a17:902:d2c9:b0:2cc:6018:f030 with SMTP id d9443c01a7336-2d0521bb7cbmr117871245ad.14.1785817148639; Mon, 03 Aug 2026 21:19:08 -0700 (PDT) Received: from [127.0.1.1] ([188.253.12.32]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d04b0ea84asm46012645ad.43.2026.08.03.21.19.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 21:19:08 -0700 (PDT) From: Jia Jia To: mst@redhat.com Cc: stefanha@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] vhost/vsock: discard IOTLB when ACCESS_PLATFORM is cleared Date: Tue, 4 Aug 2026 12:18:50 +0800 Message-Id: <20260804041850.5922-1-physicalmtea@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260803231405-mutt-send-email-mst@kernel.org> References: <20260730104857-mutt-send-email-mst@kernel.org> <20260731103414.1746316-1-physicalmtea@gmail.com> <20260731103414.1746316-2-physicalmtea@gmail.com> <20260803231405-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Mon, Aug 03, 2026 at 11:18:50PM -0400, Michael S. Tsirkin wrote: > Why lock down all vqs like this? Would this work just as well instead? > > iotlb = vsock->dev.iotlb; > vsock->dev.iotlb = NULL; > > for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) { > mutex_lock(&vsock->vqs[i].mutex); > vq = &vsock->vqs[i]; > vq->iotlb = NULL; > memset(vq->meta_iotlb, 0, sizeof(vq->meta_iotlb)); > vq->acked_features = features; > mutex_unlock(&vsock->vqs[i].mutex); > } > > and if no why not? Thanks for the review. My understanding is as follows. The proposed sequence protects the lifetime of the old IOTLB, but it does not keep the translation state consistent during the transition. dev->iotlb is shared by all VQs, while vq->iotlb, meta_iotlb, and acked_features are per-VQ state. A kick handler only holds its own VQ mutex. If dev->iotlb is cleared first, a handler that already holds a VQ mutex can continue using the old vq->iotlb and metadata cache, while translate_desc() sees dev->iotlb == NULL and falls back to dev->umem. The same handler could therefore observe both the IOVA/IOTLB and GPA/umem views. Locking each VQ in turn before freeing the old IOTLB prevents a lifetime issue, but it does not remove this mixed-state window. Taking all VQ mutexes before changing dev->iotlb lets active handlers finish and prevents new handlers from running until the shared and per-VQ state has been updated consistently. If VHOST_SET_FEATURES is guaranteed to run only while all VQs are stopped or otherwise quiesced, then the shorter sequence should be sufficient. Since the ioctl itself does not enforce that, I thought this transition also needed to be safe while a VQ may still be active. Please correct me if I have misunderstood anything. Thank you very much.