From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 6FD7330C164 for ; Fri, 31 Jul 2026 04:42:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785472935; cv=none; b=CEtGYExnIrRn94g8WogfoN5fzfIc4+1jjeLNDH1+iZdTet/2aJy9T5/yqab0zOaKdZpk677Vs33J6oMadqB+sDLPeZc8rfQ5rBnIkFLyLVAWJozTlPXB+AHm52HXKTkPz6CvD/oqDLsmHu4nZEmD7Lznl6ydzVrfSxdgZNgk+2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785472935; c=relaxed/simple; bh=ZMvyUCyEVG3QAjdzCqMKBgh7MXLqXhHhJWMaYN5xfHY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=oQAqvbvs9+GpmLDgXa0N9Z3Zj2wPmVyasbRrpZYBoKg+K8komGKdbLjn9nGgWwDlaVRYCIC7/9epGRjzkx7D6gYHdlX109he5p92A+1RAdHHZsHIsLX7FKNne+SNkQZuiP5QwWMvNVTXTxNTrIffH03YW/ajBy8cpjOFiIiq89E= 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=ftGY2Zkq; arc=none smtp.client-ip=209.85.214.177 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="ftGY2Zkq" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2caced6038eso4384055ad.0 for ; Thu, 30 Jul 2026 21:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785472934; x=1786077734; 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=UBxrxqOA4cNRIKhpkuQrq3xtaL8oWVG4/TQjb10K0NA=; b=ftGY2ZkqIkWsezngXcYhdKiI3gUJdkepw3zIrRZw6yniQCExtyZZNfFTCwIRbV/CaJ cq1yKX2KxnnlabdoEbJfQMamnxJTXidlXTTtw7sjYouec70FUvbCOIeT+a2qap0+KP/u EhLPN7tNKEl9oEbFa1rfRoeRw9kNQbz1r4CITrFJLRP5fqeMyQbz99KytMqtD9fTox8R AbNCxcsb0zPoLg4BU+rMcPrJac59kjuTcFHnniS4QdwtPCBWBSwLCxSxvBigWERkda+F RMCn3SQiTrsDdPsgyyuUuTFx5/c2ubXdal122rWKDIQOJsTF5JmevyGEhbBR+AmXcZPc B8Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785472934; x=1786077734; 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=UBxrxqOA4cNRIKhpkuQrq3xtaL8oWVG4/TQjb10K0NA=; b=ReaiHX2Ho5u+fHEd4XGXRAyZOAkgtwuYmAgaGckTfJzVC75Cf5+qCq6M6+YvGX4D0d mFt55yVKGbWddNS5fumz+6qxON1zW9YWNSIG+XGwkliUjX23jSFDCSc4PblLmE0JLih5 78GdE07Q2WRjn0EE1CJoAx2qQuUrwh/tLgZmp4lKp0HtnoetlMXQo8LRGV5Cwa8tQ8p0 7L+2Vqz+4wlD6Qj8JKza8RTd8nQ6wU64G0uH5ax9xYRZu5FKmmmYYxxgNuz42eXxiiW4 nncS8+g3p42oMvfQRKDJYnQwsuMBs2JYn16aE0fRjM3RhN/Nlw5oyWLfrZRQIQLEKsz+ H3Cw== X-Forwarded-Encrypted: i=1; AHgh+Rox2WzvMUYuq/6BCnCEAGEsZzDoHfEKUMYT4tWiyq5+RDLJA//oXe2kpvWlrZu5BIi7UPVK8rN/8sFW67c=@vger.kernel.org X-Gm-Message-State: AOJu0Ywz23cnkRXli6rY7YSrcGRh5otlwIqyRGMW5EbGu86wX7WLvFIt ET8sUC4Utt4l06G8yCPQlRdXmWQ6Cr2R84e9MJvKmMwnE4byDJgsTlA6 X-Gm-Gg: AR+sD102Dx/kn3mtHVqu+bNLfUNunrobVo5LFfCumMMsz6VXDb2/zspTELnnrOzKiOU ieKAc0kkBSOnxBF80ct6FPk4Hb8QGBB4tC8EuYCByfaNUiL9OxRlqHipSUUzOqrc+OgyShHDsU6 QKd4dcm6mM8E0lGAu7O5DnXY/KbYF8iUACyDRThv+JJP784YFA/PGzrpTU4JwLkWKFOvjiDpCW0 mHridCKEeg7zozHch8FS5MsynpilUEKib60ZRJim8jfRYUixvaOI3NvEdCq5HJKSEFsBkHlvwj6 8rPao/uDHtp+NWno2Ki9s7fFGkplOh+noCpbxJtlB/l7Y9usBvlGGtaSSVCS/sfF3oInOfSw43z JMYC1YQKZ+c6q8F+NbwjfywxekDgLs/IO7sZs/5AjdxbuLcGf02yyKNDJ/YQoLghjnZpui1VnfV UdXtC55tEwlNaioIK6HUmJh5O+CBnG5n01BSYtTq2u8HuznRj4mDYQIM5bC004tuM= X-Received: by 2002:a17:902:ceca:b0:2cc:ac15:ff4c with SMTP id d9443c01a7336-2d047d5481cmr4191885ad.8.1785472933339; Thu, 30 Jul 2026 21:42:13 -0700 (PDT) Received: from [127.0.1.1] ([188.253.12.32]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3153dd9c93dsm765243eec.8.2026.07.30.21.42.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 21:42:12 -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] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes Date: Fri, 31 Jul 2026 12:41:45 +0800 Message-Id: <20260731044145.1734317-1-physicalmtea@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260730104857-mutt-send-email-mst@kernel.org> References: <20260730104857-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 Thu, Jul 30, 2026 at 10:51:15AM -0400, Michael S. Tsirkin wrote: > I don't know if this will break anything. Why not just blow > out the iotlb? kernel will rebuild it if it needs it afterwards > for some reason. > > This part you are fixing is harmless. Let's make it a separate patch > and document the motivation. Thanks. Yes, I considered discarding the IOTLB before choosing -EBUSY. My hesitation was not about whether it could eventually be rebuilt, but that doing so would no longer be only a control-plane validation change. It would modify translation state directly used by running virtqueues. The minimum synchronization I had in mind was roughly: vhost_vsock_set_features(features): mutex_lock(dev.mutex) if (!(features & ACCESS_PLATFORM) && dev.iotlb): lock all vq.mutex in index order old = dev.iotlb dev.iotlb = NULL for each vq: vq.iotlb = NULL reset vq.meta_iotlb vq.acked_features = features unlock all vq.mutex vhost_iotlb_free(old) ... mutex_unlock(dev.mutex) The switch has to be serialized against all active VQs. My hesitation was that this turns VHOST_SET_FEATURES into a datapath synchronization point: the ioctl may wait for in-flight kick handlers, and rebuilding an empty IOTLB may stall queues on misses until the translations are restored. If stopping or flushing the device is also required, the disruption is larger than a normal feature update. I was not sure whether VHOST_SET_FEATURES is expected to impose that cost on a running device, or whether userspace should quiesce it first. That is why I chose -EBUSY for v1. If synchronization with active VQs is the intended behavior here, I can rework the patch accordingly. I will also split the existing-IOTLB preservation change into a separate patch and document its motivation.