From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jia Jia <physicalmtea@gmail.com>
Cc: sgarzare@redhat.com, mst@redhat.com, jasowang@gmail.com,
eperezma@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes
Date: Thu, 30 Jul 2026 09:55:08 -0400 [thread overview]
Message-ID: <20260730135508.GC1442692@fedora> (raw)
In-Reply-To: <20260730040938.1725757-1-physicalmtea@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]
On Thu, Jul 30, 2026 at 12:09:38PM +0800, Jia Jia wrote:
> 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;
> + }
This prevents one problem but there are still other issues with how
feature bit negotiation and the IOTLB are implemented:
1. VIRTIO_F_ACCESS_PLATFORM is defined by the VIRTIO spec and must not
be change after feature bit negotiation. Please reject all feature
bit updates except VHOST_F_LOG_ALL to comply with the VIRTIO spec and
eliminate potential bugs in drivers/vhost/vsock.c.
2. When the device is reset, the iotlb cannot be left initialized
because there is no guarantee that VIRTIO_F_ACCESS_PLATFORM will be
negotiated again.
> + 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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-07-30 13:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 4:09 [PATCH] vhost/vsock: prevent stale IOTLB after ACCESS_PLATFORM changes Jia Jia
2026-07-30 4:36 ` sashiko-bot
2026-07-30 13:55 ` Stefan Hajnoczi [this message]
2026-07-30 14:48 ` Michael S. Tsirkin
2026-07-30 14:51 ` Michael S. Tsirkin
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=20260730135508.GC1442692@fedora \
--to=stefanha@redhat.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=physicalmtea@gmail.com \
--cc=sgarzare@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.