From: Jia Jia <physicalmtea@gmail.com>
To: stefanha@redhat.com, sgarzare@redhat.com, mst@redhat.com,
jasowang@gmail.com
Cc: eperezma@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes
Date: Thu, 30 Jul 2026 12:09:38 +0800 [thread overview]
Message-ID: <20260730040938.1725757-1-physicalmtea@gmail.com> (raw)
vhost_vsock_set_features() initializes dev->iotlb when
VIRTIO_F_ACCESS_PLATFORM is enabled. It does not remove that IOTLB
when the feature is later cleared. The virtqueue still points at the
old IOTLB, and vhost_vsock_handle_tx_kick() passes descriptors to
vhost_get_vq_desc(), which translates them through that mapping.
A userspace backend can enable ACCESS_PLATFORM, install an IOTLB entry
for a payload GPA, start the device, clear ACCESS_PLATFORM, replace the
memory table, and reuse the old HVA before submitting the same GPA
again. The feature state then says direct memory access is in use
while the TX path still uses the old IOTLB HVA.
Reject clearing ACCESS_PLATFORM while the device IOTLB exists. Also
keep the existing IOTLB when a feature update leaves ACCESS_PLATFORM
enabled; VHOST_SET_FEATURES is used for runtime log updates and must
not discard the current translations by allocating an empty IOTLB.
Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support")
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
---
drivers/vhost/vsock.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index ae01457ea2cd..57e8fd1eb670 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -798,6 +798,7 @@ static int vhost_vsock_set_cid(struct vhost_vsock *vsock, u64 guest_cid)
static int vhost_vsock_set_features(struct vhost_vsock *vsock, u64 features)
{
struct vhost_virtqueue *vq;
+ int ret = -EFAULT;
int i;
if (features & ~VHOST_VSOCK_FEATURES)
@@ -809,7 +810,14 @@ static int vhost_vsock_set_features(struct vhost_vsock *vsock, u64 features)
goto err;
}
- if ((features & (1ULL << VIRTIO_F_ACCESS_PLATFORM))) {
+ if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)) &&
+ vsock->dev.iotlb) {
+ ret = -EBUSY;
+ goto err;
+ }
+
+ if ((features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)) &&
+ !vsock->dev.iotlb) {
if (vhost_init_device_iotlb(&vsock->dev))
goto err;
}
@@ -827,7 +835,7 @@ static int vhost_vsock_set_features(struct vhost_vsock *vsock, u64 features)
err:
mutex_unlock(&vsock->dev.mutex);
- return -EFAULT;
+ return ret;
}
static long vhost_vsock_dev_ioctl(struct file *f, unsigned int ioctl,
--
2.34.1
next reply other threads:[~2026-07-30 4:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 4:09 Jia Jia [this message]
2026-07-30 4:36 ` [PATCH] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes sashiko-bot
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=20260730040938.1725757-1-physicalmtea@gmail.com \
--to=physicalmtea@gmail.com \
--cc=eperezma@redhat.com \
--cc=jasowang@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.