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
signature.asc
Description: PGP signature
