Re: [GSoC 2026] vhost-user memory isolation proposal feedback request

[Hanna Czenczek <hreitz@redhat.com>]

On 09.03.26 12:17, Han Zhang wrote:
> Hello,
>
> My name is Han. I previously implemented a virtio-based communication
> mechanism between confidential virtual machines, and based on that
> experience I would like to apply for the QEMU GSoC 2026 project
> "vhost-user memory isolation". Before finalizing my proposal, I would
> like to check whether my understanding of the project direction is
> correct.

Hello Han!

Thank you for your interest in this project, good to hear you already 
have experience with virtio!

> My current understanding is:
> without changing the existing vhost-user protocol, add a
> memory-isolation mode for vhost-user devices so the backend no longer
> directly accesses guest RAM. Instead, QEMU intercepts virtqueue
> requests, copies data between guest RAM and isolated buffers, and
> forwards notifications. The backend only sees QEMU-managed shadow
> virtqueues and descriptors pointing to isolated buffers.

That is correct.

> After reading the relevant code paths around vhost-user-blk and SVQ,
> my current understanding of the required work is roughly:
> 1. Extend the generic SVQ path for the vhost-user case, including
> adding a used_handler so completion handling can perform copy-back and
> cleanup before returning requests to the guest virtqueue.

You mean used_handler as a counterpart to avail_handler?  That makes 
sense indeed.

> 2. Move the SVQ vring memory to memfd-backed shared regions and
> register them with the backend through add-mem-reg/rem-mem-reg, so the
> userspace backend can access the shadow vring.

That must happen in some capacity, although I would have assumed that 
there is already a mechanism for this, for the vring memory itself.

> 3. Allocate bounce or isolated buffers at the SVQ callback point, copy
> data from the guest virtqueue into those buffers, forward rewritten
> descriptors to the backend, and copy data back on completion.

Right.  And these too would need to be shared with the back-end, too.  
Ideally, they are cached, of course, to reduce the number of buffer 
add/remove functions that need to be run.

> I am mainly trying to validate whether this is the right architectural
> direction, especially the split between generic reusable vhost-user
> SVQ code and device-specific handling such as the vhost-user-blk
> bounce-buffer path.
>
> I would appreciate feedback on the following:
> 1. Is this interpretation of the core goal correct, especially "QEMU
> performs data copy, backend only sees isolated memory + SVQ"?

Yes, it is.

> 2. For isolated buffers, is qemu_memfd_alloc + add-mem-reg the
> preferred direction, or is there a better approach?

I’ll defer to Tyler and Stefan on this, but in general, I would say if 
it works, it works.  It does sound good to me, fwiw.

> 3. For code organization, what split is preferred between generic
> vhost-user code and device-specific code (for example vhost-user-blk)?

Ideally, it is completely generic, nothing in the device-specific code.

> This is my first time participating in an open source project, so I
> would greatly appreciate any correction or guidance.

Perfect for GSoC! :)

Hanna

> Thank you very much for your time.
>
> Best regards,
> Han
>