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

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Mon, Feb 10, 2020 at 02:38:56PM +0100, Gerd Hoffmann wrote:
> > #3 is pretty similar to #1 in its design except that, instead of using
> > the VSOCK infrastructure it's using a new type of virtio device. I
> > guess it has the same pros and cons #1 has, and the name should probably
> > be changed to reflect the fact that it can transmit any kind of data not
> > just wayland.
> 
> Even though vsock looks simple at first it isn't when you look at the
> details.  You'll want support more streams than virtqueues.  So you'll
> go multiplex.  You want good performance, but you also don't want allow
> streams to DoS the device by filling up the queue.
> 
> Thats why I don't like the new virtio device idea much and would prefer
> vhost being reused, either directly (#1) or via proxy (#2).
> 
> Note that vhost aims to be hypervisor-agnostic and we have (unless I
> missed something) three transports for it: virtio, vmware and hyperv.
> So extending that with virtio-only features might not be the best idea.

s/vsock/vhost/

> Also it is a fact that approach #1 didn't went anywhere so far but we
> have a working implementation of approach #3.  So I guess I wouldn't
> veto approach #3 if you pick it after evaluating the options on the
> table.
> 
> Final note: We have a new kid on the block: virtio-fs.  I think
> virtio-fs with dax enabled should allow for shared file mappings between
> host and guest.  That is something a proxy (#2) might be able to make
> use of.

Yes, virtio-fs allows the guest to directly map files from the host.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]