On 05.02.26 11:37, Michael S. Tsirkin wrote:
On Thu, Feb 05, 2026 at 11:22:26AM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 05.02.26 11:13, Michael S. Tsirkin wrote:
On Wed, Feb 04, 2026 at 12:23:39PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Unlike the kernel, vhost-user backend knows nothing about QEMUs
userspace addresses. We can pass GPA instead and nothing changes.
The benefit: open the doors for further implementation of local
migration (live-update) with passing open vhost-releated FDs
through UNIX domain socket. This way the connection with backend
kept live and untouched.
Without this change, we'll have to communicate with backend to
inform it about UVA addresses change, but better is simply use
more stable GPA numbers, like it's done for VDPA.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
---
hw/virtio/vhost-user.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 63fa9a1b4b..f379408c95 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -386,6 +386,24 @@ static int vhost_user_write(struct vhost_dev *dev,
VhostUserMsg *msg,
CharFrontend *chr = u->user->chr;
int ret, size = VHOST_USER_HDR_SIZE + msg->hdr.size;
+ if (msg->hdr.request == VHOST_USER_REM_MEM_REG ||
+ msg->hdr.request == VHOST_USER_ADD_MEM_REG) {
+
+ /*
+ * In QEMU we pass guest physical addresses to vhost-user server
+ * instead of QEMUs virtual address. Server have no option to
+ * distinguesh,
what does this mean? "Servers don't really care"?
Yes. Still, we can't be sure, what servers care about. But I think, as
they don't have any access to QEMUs virtual address space, they can't
have any logic that breaks if we start to pass GPA instead of UVA
(imagine, that "accidentally" GPA and UVA are the same for the case).
right, just write something understandable pls.
but we get a benefit: guest physical address is
+ * stable during migration, and we don't have to reset memory
+ * regions.
curious if PA 0 is valid on some systems (as opposed to VA).
Hmm, you are right, that's visible thing which differs for UVA and GPA.
Still, checking UVA to be non-zero on server side seems rather strange,
as the only use for these UVA addresses in the server is to calculate
offsets. The server is only interested in offsets inside given memory
region, not absolute UVA values.
And we don't write in spec that UVA can't be zero, and we already use
GPA for VDPA.
poking at some servers to make sure can't hurt.
I can't believe it. I checked DPDK vhost-user implementation - it seems OK.
But our own vhost-user server in QEMU does this:
static bool
vu_is_vq_usable(VuDev *dev, VuVirtq *vq)
{
if (unlikely(dev->broken)) {
return false;
}
if (likely(vq->vring.avail)) {
return true;
}
/*
* In corner cases, we might temporarily remove a memory region that
* mapped a ring. When removing a memory region we make sure to
* unmap any rings that would be impacted. Let's try to remap if we
* already succeeded mapping this ring once.
*/
if (!vq->vra.desc_user_addr || !vq->vra.used_user_addr ||
<<<<<<<<<<<<<<<<<<<<
!vq->vra.avail_user_addr) {
return false;
}
if (map_ring(dev, vq)) {
vu_panic(dev, "remapping queue on access");
return false;
}
return true;
}
It really check whether the received "userspace" addresses are zero. Fantastic.
Hmm.. Seems that we need a feature flag to live without UVA addresses. In the
long
run, it's better than hacking.
+ *
+ * Look also at vhost_user_vq_get_addr(): like in VDPA, we pass
+ * physical addresses instead of user.
+ */
+
+ msg->payload.mem_reg.region.userspace_addr =
+ msg->payload.mem_reg.region.guest_phys_addr;
+ }
+
/*
* Some devices, like virtio-scsi, are implemented as a single vhost_dev,
* while others, like virtio-net, contain multiple vhost_devs. For
@@ -3021,6 +3039,17 @@ static int vhost_user_check_device_state(struct
vhost_dev *dev, Error **errp)
return 0;
}
+static int vhost_user_vq_get_addr(struct vhost_dev *dev,
+ struct vhost_vring_addr *addr,
+ struct vhost_virtqueue *vq)
+{
+ assert(dev->vhost_ops->backend_type == VHOST_BACKEND_TYPE_USER);
+ addr->desc_user_addr = (uint64_t)(unsigned long)vq->desc_phys;
+ addr->avail_user_addr = (uint64_t)(unsigned long)vq->avail_phys;
+ addr->used_user_addr = (uint64_t)(unsigned long)vq->used_phys;
+ return 0;
+}
+
const VhostOps user_ops = {
.backend_type = VHOST_BACKEND_TYPE_USER,
.vhost_backend_init = vhost_user_backend_init,
@@ -3059,4 +3088,5 @@ const VhostOps user_ops = {
.vhost_supports_device_state = vhost_user_supports_device_state,
.vhost_set_device_state_fd = vhost_user_set_device_state_fd,
.vhost_check_device_state = vhost_user_check_device_state,
+ .vhost_vq_get_addr = vhost_user_vq_get_addr,
};
--
2.52.0
--
Best regards,
Vladimir
--
Best regards,
Vladimir
