From: Jia Jia <physicalmtea@gmail.com>
To: sgarzare@redhat.com
Cc: stefanha@redhat.com, mst@redhat.com, jasowangio@gmail.com,
eperezma@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] vhost/vsock: discard IOTLB when ACCESS_PLATFORM is cleared
Date: Fri, 14 Aug 2026 12:30:52 +0800 [thread overview]
Message-ID: <20260814043052.59578-1-physicalmtea@gmail.com> (raw)
In-Reply-To: <an2KTuUm-mZ0nnDQ@sgarzare-redhat>
> You can assing vq before the mutex_lock() and use it there too (and in
> mutex_unlock()), as we do in all other places in this file.
Sure, will do.
> I don't see anything vsock specific here. Would it be better to move
> this to vhost.c and reuse some of the functions we have there?
>
> I mean something like this (untested and may be incomplete):
>
> void vhost_clear_device_iotlb(struct vhost_dev *d)
> {
> struct vhost_iotlb *iotlb;
> int i;
>
> iotlb = d->iotlb;
> d->iotlb = NULL;
>
> for (i = 0; i < d->nvqs; ++i) {
> struct vhost_virtqueue *vq = d->vqs[i];
>
> mutex_lock(&vq->mutex);
> vq->iotlb = NULL;
> __vhost_vq_meta_reset(vq);
> mutex_unlock(&vq->mutex);
> }
>
> vhost_clear_msg(d);
> vhost_iotlb_free(iotlb);
> wake_up_interruptible_poll(&d->wait, EPOLLIN | EPOLLRDNORM);
> }
> EXPORT_SYMBOL_GPL(vhost_clear_device_iotlb);
Thanks for the detailed feedback. There has been some evolution behind
this patch. The work originally started from a vhost-scsi bug. After
Stefan Hajnoczi pointed out that vhost-net and vhost-vsock might have the
same underlying issue, the first version used a feature-change rejection
approach. The vhost-net patch from that stage is:
https://lore.kernel.org/all/20260726141158.1652386-1-physicalmtea@gmail.com/
Michael S. Tsirkin then suggested that simply rejecting the change was
not the best way to handle the IOTLB transition, and suggested discarding
the existing IOTLB instead. That led to the current vhost-vsock patch.
The vhost-net patch already preserves an existing IOTLB when
ACCESS_PLATFORM remains enabled, as in patch 2 here. For clearing
ACCESS_PLATFORM, the two versions currently use different policies:
vhost-net rejects the live change with -EBUSY, while this vhost-vsock
series accepts the change and tears down the old IOTLB. The vhost-net
patch also addresses a separate live IN_ORDER transition issue.
I initially kept the helper in vsock.c because I was unsure whether
changing the common vhost code was appropriate. Looking at the code,
however, the IOTLB teardown has no dependency on vsock- or net-specific
state. Unless there are other concerns, I will move the helper to
vhost.c in the next revision and apply the same IOTLB teardown handling
to vhost-net as well. I will keep the acked_features updates in each
backend's own loop, while retaining the vhost-net-specific checks for
IN_ORDER and other unsafe feature changes.
> TBH I don't like this mix.
>
> Why assigning acked_features inside vhost_vsock_clear_iotlb()?
>
> IMO it's confusing. I see that you're saving another loop around the
> VQs, but this code is not easy to understand IMO.
>
> I think we have 2 options:
> 1. leave the loop for acked_features and don't set it in
> vhost_vsock_clear_iotlb() (less code touched by this patch).
> This is also what to do if we move the clear_iotlb() function
> in vhost.c.
> 2. change the code to have a single for loop with if block inside to
> reset IOTLB stuff if needed. In this case maybe better to avoid the
> function and move the entire code here.
>
> I prefer 1 with clear_iotlb() in vhost.c, but I'm not fully against 2.
Thanks for understanding that the original intent was to avoid an extra loop.
I agree that assigning acked_features in vhost_vsock_clear_iotlb() is confusing,
so I'll follow option 1 in the next version.
Thanks,
Jia
next prev parent reply other threads:[~2026-08-14 4:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260810134018.143973-1-physicalmtea@gmail.com>
[not found] ` <20260810134018.143973-2-physicalmtea@gmail.com>
2026-08-13 9:39 ` [PATCH v3 1/2] vhost/vsock: discard IOTLB when ACCESS_PLATFORM is cleared Stefano Garzarella
2026-08-14 4:30 ` Jia Jia [this message]
[not found] ` <20260810134018.143973-3-physicalmtea@gmail.com>
2026-08-13 9:44 ` [PATCH v3 2/2] vhost/vsock: keep IOTLB across feature updates Stefano Garzarella
2026-08-14 4:31 ` Jia Jia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260814043052.59578-1-physicalmtea@gmail.com \
--to=physicalmtea@gmail.com \
--cc=eperezma@redhat.com \
--cc=jasowangio@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox