Re: [PATCH] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes

[Jia Jia <physicalmtea@gmail.com>]

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.