Re: [RFC v4 0/5] Add virtio transport for AF_VSOCK

[Stefan Hajnoczi <stefanha@gmail.com>]

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

On Mon, Jan 04, 2016 at 03:55:35PM +0800, Jason Wang wrote:
> 
> 
> On 12/22/2015 05:07 PM, Stefan Hajnoczi wrote:
> > This series is based on v4.4-rc2 and the "virtio: make find_vqs()
> > checkpatch.pl-friendly" patch I recently submitted.
> >
> > v4:
> >  * Addressed code review comments from Alex Bennee
> >  * MAINTAINERS file entries for new files
> >  * Trace events instead of pr_debug()
> >  * RST packet is sent when there is no listen socket
> >  * Allow guest->host connections again (began discussing netfilter support with
> >    Matt Benjamin instead of hard-coding security policy in virtio-vsock code)
> >  * Many checkpatch.pl cleanups (will be 100% clean in v5)
> >
> > v3:
> >  * Remove unnecessary 3-way handshake, just do REQUEST/RESPONSE instead
> >    of REQUEST/RESPONSE/ACK
> >  * Remove SOCK_DGRAM support and focus on SOCK_STREAM first
> >    (also drop v2 Patch 1, it's only needed for SOCK_DGRAM)
> >  * Only allow host->guest connections (same security model as latest
> >    VMware)
> >  * Don't put vhost vsock driver into staging
> >  * Add missing Kconfig dependencies (Arnd Bergmann <arnd@arndb.de>)
> >  * Remove unneeded variable used to store return value
> >    (Fengguang Wu <fengguang.wu@intel.com> and Julia Lawall
> >    <julia.lawall@lip6.fr>)
> >
> > v2:
> >  * Rebased onto Linux v4.4-rc2
> >  * vhost: Refuse to assign reserved CIDs
> >  * vhost: Refuse guest CID if already in use
> >  * vhost: Only accept correctly addressed packets (no spoofing!)
> >  * vhost: Support flexible rx/tx descriptor layout
> >  * vhost: Add missing total_tx_buf decrement
> >  * virtio_transport: Fix total_tx_buf accounting
> >  * virtio_transport: Add virtio_transport global mutex to prevent races
> >  * common: Notify other side of SOCK_STREAM disconnect (fixes shutdown
> >    semantics)
> >  * common: Avoid recursive mutex_lock(tx_lock) for write_space (fixes deadlock)
> >  * common: Define VIRTIO_VSOCK_TYPE_STREAM/DGRAM hardware interface constants
> >  * common: Define VIRTIO_VSOCK_SHUTDOWN_RCV/SEND hardware interface constants
> >  * common: Fix peer_buf_alloc inheritance on child socket
> >
> > This patch series adds a virtio transport for AF_VSOCK (net/vmw_vsock/).
> > AF_VSOCK is designed for communication between virtual machines and
> > hypervisors.  It is currently only implemented for VMware's VMCI transport.
> >
> > This series implements the proposed virtio-vsock device specification from
> > here:
> > http://permalink.gmane.org/gmane.comp.emulators.virtio.devel/980
> >
> > Most of the work was done by Asias He and Gerd Hoffmann a while back.  I have
> > picked up the series again.
> >
> > The QEMU userspace changes are here:
> > https://github.com/stefanha/qemu/commits/vsock
> >
> > Why virtio-vsock?
> > -----------------
> > Guest<->host communication is currently done over the virtio-serial device.
> > This makes it hard to port sockets API-based applications and is limited to
> > static ports.
> >
> > virtio-vsock uses the sockets API so that applications can rely on familiar
> > SOCK_STREAM semantics.  Applications on the host can easily connect to guest
> > agents because the sockets API allows multiple connections to a listen socket
> > (unlike virtio-serial).  This simplifies the guest<->host communication and
> > eliminates the need for extra processes on the host to arbitrate virtio-serial
> > ports.
> >
> > Overview
> > --------
> > This series adds 3 pieces:
> >
> > 1. virtio_transport_common.ko - core virtio vsock code that uses vsock.ko
> >
> > 2. virtio_transport.ko - guest driver
> >
> > 3. drivers/vhost/vsock.ko - host driver
> 
> Have a (dumb maybe) question after a quick glance at the codes:
> 
> Is there any chance to reuse existed virtio-net/vhost-net codes? For
> example, using virito-net instead of a new device as a transport in
> guest and using vhost-net (especially consider it uses a socket as
> backend) in host. Maybe just a new virtio-net header type for vsock. I'm
> asking since I don't see any blocker for doing this.

virtio-net is an Ethernet device with best-effort delivery while
virtio-vsock is guaranteed delivery.  That's the fundamental difference
at the protocol level.

At the driver level AF_VSOCK isn't supposed to have a netdev or
user-visible network interface that can be misconfigured by the guest
administrator.

Trying to make the existing virtio-net device work for this use case is
probably nastier than using a dedicated device since lot of the
virtio-net configuration space and control features don't make sense for
AF_VSOCK.

Stefan

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