On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote: > On Mon, 17 Feb 2020 19:21:50 +0100 > Boris Brezillon <boris.brezil...@collabora.com> wrote: > > > > > 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). > > > > > > For crosvm's purposes, we are looking at ways to reduce vhost usage in > > > order to reduce host kernel exposure to untrusted guest input, > > > including from the guest kernel. That is why a non-vhost based > > > solution would be prefered. > > > > Okay, I didn't know you were avoiding vhost-based solutions to > > reduce the attack surface. > > Looks like they implemented vhost-less vsock in Firecracker[1]. Not > sure how much work that would be to port this implementation to crosvm, > but maybe that's an option. > > [1]https://github.com/firecracker-microvm/firecracker/pull/1176
Well, the nice thing about vsock is that (a) you have the same interface on guest and host, and (b) it is hypervisor-agnostic. Applications can simply use the usual system calls (socket, bind, listen, connect) with AF_VSOCK socket type and be done with it. When not using vhost this goes away (on the host side). firecracker seems to have a vsock <-> unix socket bridge in vmm userspace instead (pull req msg sounds like that, didn't check the code). I think there can be only one vsock device per guest. So you can't have multiple instances, one with a vsock backend on the host and one with a userspace backend on the host, then pick one of the two depending on the use case. So, one advantage of a separate device would be that we'll gain some flexibility in terms of the host side implementation. vsock vhost can be used together with a wayland userspace backend. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org