Re: [RFC] Upstreaming virtio-wayland (or an alternative)

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 7 Feb 2020 18:28:42 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> Based on all previous discussions, I could identify 3 different
> approaches:
> 
>     1/ Use VSOCK and extend it to support passing (some) FDs
>     2/ Use a user space VSOCK-based proxy that's in charge of
>        a/ passing regular messages
>        b/ passing specific handles to describe objects shared
>           between host and guest (most focus has been on dmabufs as
>           this is what we really care about for the gfx use case,
>           but other kind of FDs can be emulated through a
>           VSOCK <-> UNIX_SOCK bridging)
>     3/ Have a dedicated kernel space solution that provides features
>        exposed by #1 but through a virtio device interface (basically
>        what virtio-wayland does today)
> 
> Each of them has its pros and cons, which I'll try to sum-up (please
> correct me if I'm wrong, and add new things if you think they are
> missing).
> 
> #1 might require extra care if we want to make it safe, as pointed
> out by Stefan here [4] (but I wonder if the problem is not the same
> for a virtio-wayland based solution). Of course you also need a bit of
> infrastructure to register FD <-> VFD mappings (VFD being a virtual
> file descriptor that's only used as unique IDs identifying the resource
> backed by the local FD). FD <-> VFD mappings would have to be created
> by the subsystem in charge of the object backing the FD (virtio-gpu for
> exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> sockets if we decide to bridge unix and vsock sockets to make it
> transparent, ...). The FD <-> VFD mapping would also have to be created
> on the host side, probably by the virtio device implementation
> (virglrenderer for GEM bufs for instance), which means host and guest
> need a way to inform the other end that a new FD <-> VFD mapping has
> been created so the other end can create a similar mapping (I guess this
> requires extra device-specific commands to work).

We might be able to do that lazily if we add
->virtio_fd_to_vfd()/->virtio_vfd_to_fd() hooks to the file_operations
struct, instead of expecting the subsystem to pro-actively create those
mappings (when those hooks are not implemented, that means the resource
backed by this FD can't be passed on a VSOCK). Anyway, that's just an
implementation detail, the first question being, should we pursue in
this direction or not?