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

[Michael S. Tsirkin]

On Fri, Jul 31, 2026 at 12:41:45PM +0800, Jia Jia wrote:
> 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.

thanks