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
