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@xxxxxxxx>) > > * Remove unneeded variable used to store return value > > (Fengguang Wu <fengguang.wu@xxxxxxxxx> and Julia Lawall > > <julia.lawall@xxxxxxx>) > > > > 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:
signature.asc
Description: PGP signature
