From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8739C3932F9 for ; Tue, 4 Aug 2026 03:18:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785813540; cv=none; b=CquSDzRfEL03mGtvxSJDOVy66Xal1evaAWEaeyCaae26qkI80In12WjP4TJFlWF/2UlbudObnOHT1vvEMlBHFo2y0304CnWhys8OPUpuvuWRoeVppCKQZ6oaoVFjkcVgzYfLKAZeztg/6VtXUmPBsARSW71QW/WVyuis6lnQM14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785813540; c=relaxed/simple; bh=vjexPMXz+uHstAFBD5kC8PIMoFh7FLyMaZtlnqi/L7s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hev4g1XGilgv60zkh66HNr6nVS21YXmGgFBZ3MdlciTH1UQqQ8diSUZshI+P6UQa3eVDkNOHNRYfqFX+45xZ83i6WgkFyakDXuJtGkG33xJ99RVP0DTBkBNKEL+Vnj05UgwusRd0CViXkFL7WABQJdnbY4OzBA5106IzACltgiY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=WOsmrTl0; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=SoJi61Lv; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WOsmrTl0"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="SoJi61Lv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785813537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hn89OAtGF04fL1DOEPjseXWeO4u1I3kemB7CwT2Ey+4=; b=WOsmrTl0WPEYOFPXeNljOcoJoRUC4RfI3uHlEBrEHkt1DiNdxBxtfXtbbsJED3LveS2Kz/ 9vozBWMnJxCWerxFuy0Cq8xSmLck86C3emQbHWCvrg+c3UOCUn0LJo3wNkJO8Qdxac3xVf kjDA205eNy6LAzx3wOe8JOsTsPKcgog= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-312-KDrNS4CiOZCqyuIZRc_l9w-1; Mon, 03 Aug 2026 23:18:56 -0400 X-MC-Unique: KDrNS4CiOZCqyuIZRc_l9w-1 X-Mimecast-MFC-AGG-ID: KDrNS4CiOZCqyuIZRc_l9w_1785813535 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-6986557937eso3376731a12.3 for ; Mon, 03 Aug 2026 20:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785813535; x=1786418335; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=hn89OAtGF04fL1DOEPjseXWeO4u1I3kemB7CwT2Ey+4=; b=SoJi61LvmxaY1ZnjLpuYCCCeAGIxGAM6ju29CT3EVUQsoPGKnoG5xs4+OqUdIgLRXg E3nLwPS7VnC1DZEZGNEPG/7RDfxVzF3GEZTxwv/hvSI2xQCITE2ptnWKQTfRcQgDF2W3 TUl4ioE8NtKhG54asndOr2IX5eRpqBICV3RjM1pcxCx3GhMO+4dAh29JevvvciPxQs68 QXucKMsj3Uc36kdMVcl9xKIY5+YmFrU2Vcnn4j1rZvl5BOeYAPsNeFQ12O55/p3oCQrb SlNcOFvDVqa8poymyLbc2yd8h+pGIgrOR9GYDGTYXGm+wSEDOM/c+KzQpoNboiWtk0Dm 5DUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785813535; x=1786418335; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hn89OAtGF04fL1DOEPjseXWeO4u1I3kemB7CwT2Ey+4=; b=XrNhfjfBcx1qXRGvVQIcfYLDWHyG5U/E74b8KjX238rsKqycN8PIaaBm7WfqzHrZ8w 2M1gX9io+za+uqkKH4ueAxspJc0AbNDE6n4UW/jlHXNrlsF2YTs46LAKR00VGH48fJgj ouP5T8Hd3gVgRX8qKHYlSua0PTMR6+ZhUnZ3+vMgt1YsgxCqcpNb9DRa26NSLPgxQPoF RrrPEDijCQnlbRVhDm+pWhp6iYq5254Smg/aDEncH2AQjBRs5NCkmyiiDKJnkVsYQwM5 S/sKvDOzAjd1Vv6Dp1/dd0BY7HxS5vweyfCsJdlLZOG5UPb/2BabK+lI5g7ZuMiqGfy8 bC6g== X-Forwarded-Encrypted: i=1; AHgh+RpYov0CUQbF7qMtaH1zTakCTJrdHH7W2C0dX/ox42JzK/tzyehlmx2WsVNtp9PA11NLDw5LBsItlKXYD0c=@vger.kernel.org X-Gm-Message-State: AOJu0YxZq5KxJyBQNrLYSqXV9wi8cFO2RlEomdENcTKGN2iHTjJ+x6x8 1NFOUA0fgk1UBfHIC+/E/ynoMljrJ5acdSFVEb3wh4N6gXLoTuZQC1Ju6OcqscjTSdeOn9gSBZW gVhzQuDC1bA/LiPz+fpV1gdjQsC6qL1yTQ3/RVlkNkzUIoscIK65Gb6rH5SsFQUGMkpzmUi4d2S Ck X-Gm-Gg: AR+sD10/mrSMBqBBRUVJOp+kIZ8EUA/v8L8JEN3Id804EBBPlwIEZvKym2tC+Syp3Qs 5c49eBv6WwzGAoV2RfNSfpm4+ubSMvwKdIoViBNayIaUxhaeFFo+GH98HzDl4pQXMGABRKmsiO2 xnFQRPc/HfgV/bQqDImO4ELSHRWEoYsEOzLAtLGYgdg9psyBZTqoMgP5paAyRvnNxcHUmDBcoAr Ypnp65ysX18I8OWT4k1FHVzdbreP9I+gGQxB/lSoX6gufjIFEC/neQ+tM7HAH16DLlWpvkROs8l YLiHdojiE+25WHmbw3Cnj4Teix3z8BcnRSaB4zgSNTQ7+1LmP5QPhH6wj/5HzSau9uIQ X-Received: by 2002:a05:6402:42c8:b0:6a1:2400:baea with SMTP id 4fb4d7f45d1cf-6a12400bf12mr1998129a12.10.1785813534913; Mon, 03 Aug 2026 20:18:54 -0700 (PDT) X-Received: by 2002:a05:6402:42c8:b0:6a1:2400:baea with SMTP id 4fb4d7f45d1cf-6a12400bf12mr1998100a12.10.1785813534402; Mon, 03 Aug 2026 20:18:54 -0700 (PDT) Received: from redhat.com ([186.247.166.67]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a09c5a09acsm5960120a12.4.2026.08.03.20.18.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 20:18:53 -0700 (PDT) Date: Mon, 3 Aug 2026 23:18:50 -0400 From: "Michael S. Tsirkin" To: Jia Jia 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 Message-ID: <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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260731103414.1746316-2-physicalmtea@gmail.com> On Fri, Jul 31, 2026 at 06:34:13PM +0800, Jia Jia wrote: > vhost_vsock_set_features() leaves the device IOTLB attached when > userspace clears VIRTIO_F_ACCESS_PLATFORM. Descriptors can therefore > continue to use translations installed before the feature change, > including HVAs made stale by a later memory table update. > > Detach the IOTLB before acknowledging a feature mask without > ACCESS_PLATFORM. Hold all virtqueue mutexes in index order while clearing > the device and virtqueue IOTLB pointers, resetting metadata caches, and > updating the acknowledged features. This prevents a kick handler from > observing a mixed translation state. > > Free the old IOTLB after releasing the virtqueue mutexes. Also drop > the old IOTLB miss messages and wake readers now that the device no > longer accepts IOTLB updates. > > Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support") > Signed-off-by: Jia Jia > --- > drivers/vhost/vsock.c | 43 ++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 38 insertions(+), 5 deletions(-) > > diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c > index 9aaab6bb8061..562b9e139a76 100644 > --- a/drivers/vhost/vsock.c > +++ b/drivers/vhost/vsock.c > @@ -851,6 +851,34 @@ static int vhost_vsock_set_cid(struct vhost_vsock *vsock, u64 guest_cid) > return 0; > } > > +/* Caller must hold the device mutex. */ > +static void vhost_vsock_clear_iotlb(struct vhost_vsock *vsock, u64 features) > +{ > + struct vhost_iotlb *iotlb; > + struct vhost_virtqueue *vq; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) > + mutex_lock_nested(&vsock->vqs[i].mutex, i); > + > + iotlb = vsock->dev.iotlb; > + vsock->dev.iotlb = NULL; > + > + for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) { > + vq = &vsock->vqs[i]; > + vq->iotlb = NULL; > + memset(vq->meta_iotlb, 0, sizeof(vq->meta_iotlb)); > + vq->acked_features = features; > + } > + > + for (i = ARRAY_SIZE(vsock->vqs); i-- > 0;) > + mutex_unlock(&vsock->vqs[i].mutex); 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? > + vhost_clear_msg(&vsock->dev); > + vhost_iotlb_free(iotlb); > + wake_up_interruptible_poll(&vsock->dev.wait, EPOLLIN | EPOLLRDNORM); > +} > + > static int vhost_vsock_set_features(struct vhost_vsock *vsock, u64 features) > { > struct vhost_virtqueue *vq; > @@ -872,11 +900,16 @@ static int vhost_vsock_set_features(struct vhost_vsock *vsock, u64 features) > > vsock->seqpacket_allow = features & (1ULL << VIRTIO_VSOCK_F_SEQPACKET); > > - for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) { > - vq = &vsock->vqs[i]; > - mutex_lock(&vq->mutex); > - vq->acked_features = features; > - mutex_unlock(&vq->mutex); > + if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)) && > + vsock->dev.iotlb) { > + vhost_vsock_clear_iotlb(vsock, features); > + } else { > + for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) { > + vq = &vsock->vqs[i]; > + mutex_lock(&vq->mutex); > + vq->acked_features = features; > + mutex_unlock(&vq->mutex); > + } > } > mutex_unlock(&vsock->dev.mutex); > return 0; > -- > 2.34.1