qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status


From: Marc-André Lureau
Subject: Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update
Date: Thu, 2 Jan 2020 22:55:46 +0400

Hi

On Thu, Jan 2, 2020 at 3:03 PM Felipe Franciosi <address@hidden> wrote:
> The reason I dislike yet another offloading protocol (ie. there is
> vhost, there is vfio, and then there would be qdev-over-socket) is
> that we keep reinventing the wheel. I very much prefer picking
> something solid (eg. VFIO) and keep investing on it.

I don't have a lot of experience with VFIO, so I can't tell if it's
really solid for the user-space case. Alex W could probably discuss
that.

> In that case, wouldn't it be preferable to revive our proposal from
> Edinburgh (KVM Forum 2018)? Our prototypes moved more of the Qemu VFIO
> code to "common" and added a "user" backend underneath it, similar to
> how vhost-user-scsi moved some of vhost-scsi to vhost-scsi-common and
> added vhost-user-scsi. It was centric on PCI, but it doesn't have to
> be. The other side can be implemented in libmuser for facilitating things.

Same idea back in KVM forum 2017 (briefly mentioned at the end of our
talk with Conrad)

The PoC is still around:
https://github.com/elmarco/qemu/tree/wip/vfio-user/contrib/libvfio-user

> I even recall highlighting that vhost-user could be moved underneath
> that later, greatly simplifying lots of other Qemu code.

That would eventually be an option, but vhost-user is already quite
complicated. We could try to split it up somehow for the non-virtio
parts.

cheers

-- 
Marc-André Lureau



reply via email to

[Prev in Thread] Current Thread [Next in Thread]