Shreyansh Chouhan <email@example.com> writes:
> Just an update:
> I've studied the virtio specification along with the source code and I now
> understand what the device implementation is
> going to look like. Also I understand the source code a lot better. I am
> now reading about the qemu vhost-user protocol.
> Although I haven't read about the vhost-user daemon in detail, from what
> little I have read, I would say that the daemon
> would get the virtqueues from the virtio device and forward it to the sound
> device of the host. (This is the hard part
> I think, since an in QEMU device would use code already written for
> processing these queues.)
I can't comment on the difficulty there but this does point more towards
using the in-QEMU approach given we have a bunch of utility functions already.
> I think only the tx and rx
> queues would be shared, and although I do not know exactly how the sharing
> will be implemented, I think the memory
> will be shared to the vhost-user daemon too? So now the virtqueue memory is
> shared between the virtio driver in guest
> OS, the virtio device in QEMU, and the vhost-user daemon running in the
> host userspace.
QEMU uses a memfd file descriptor to share the guests entire memory map
with the daemon.
Oh I see.
> As for the configuration part, the driver will negotiate features with the
> virtio device in QEMU, which in turn will communicate
> with the vhost-user daemon (via sockets) to get the features supported I
> This is what I think it will roughly look like. (Of course modulo the
> implementation details.) I do not yet understand how
> much more difficult will implementing the vhost-user daemon be, and since I
> was already
> warned about the difficulty, I will not risk making any hasty decisions
> that later hinder the project. I will read up
> about the vhost-user daemon and how it's implemented to get a better idea,
> and then make the final call.
If you want to see an example of a branch new vhost-user daemon being
built up from scratch see my recent virtio-rpmb series. The first few
patches of in-QEMU code will be the same boilerplate either way I think:
This looks super helpful! Thanks a lot for this.
> Anyways I am super excited about the project. I got to learn about some
> really cool things in the past couple of days,
> and I can not wait to implement it. :)
- Shreyansh Chouhan