Most of the patches are reviewed by Dexuan, Stefan, and Jorgen.
The following patches need reviews:
- [11/15] vsock: add multi-transports support
- [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host
are active
- [15/15] vhost/vsock: refuse CID assigned to the guest->host transport
RFC: https://patchwork.ozlabs.org/cover/1168442/
v1: https://patchwork.ozlabs.org/cover/1181986/
v1 -> v2:
- Patch 11:
+ vmci_transport: sent reset when vsock_assign_transport() fails
[Jorgen]
+ fixed loopback in the guests, checking if the remote_addr is the
same of transport_g2h->get_local_cid()
+ virtio_transport_common: updated space available while creating
the new child socket during a connection request
- Patch 12:
+ removed 'features' variable in vmci_transport_init() [Stefan]
+ added a flag to register only once the host [Jorgen]
- Added patch 15 to refuse CID assigned to the guest->host transport in
the vhost_transport
This series adds the multi-transports support to vsock, following
this proposal: https://www.spinics.net/lists/netdev/msg575792.html
With the multi-transports support, we can use VSOCK with nested VMs
(using also different hypervisors) loading both guest->host and
host->guest transports at the same time.
Before this series, vmci_transport supported this behavior but only
using VMware hypervisor on L0, L1, etc.
The first 9 patches are cleanups and preparations, maybe some of
these can go regardless of this series.
Patch 10 changes the hvs_remote_addr_init(). setting the
VMADDR_CID_HOST as remote CID instead of VMADDR_CID_ANY to make
the choice of transport to be used work properly.
Patch 11 adds multi-transports support.
Patch 12 changes a little bit the vmci_transport and the vmci driver
to register the vmci_transport only when there are active host/guest.
Patch 13 prevents the transport modules unloading while sockets are
assigned to them.
Patch 14 fixes an issue in the bind() logic discoverable only with
the new multi-transport support.
Patch 15 refuses CID assigned to the guest->host transport in the
vhost_transport.
I've tested this series with nested KVM (vsock-transport [L0,L1],
virtio-transport[L1,L2]) and with VMware (L0) + KVM (L1)
(vmci-transport [L0,L1], vhost-transport [L1], virtio-transport[L2]).
Dexuan successfully tested the RFC series on HyperV with a Linux guest.
Stefano Garzarella (15):
vsock/vmci: remove unused VSOCK_DEFAULT_CONNECT_TIMEOUT
vsock: remove vm_sockets_get_local_cid()
vsock: remove include/linux/vm_sockets.h file
vsock: add 'transport' member in the struct vsock_sock
vsock/virtio: add transport parameter to the
virtio_transport_reset_no_sock()
vsock: add 'struct vsock_sock *' param to vsock_core_get_transport()
vsock: handle buffer_size sockopts in the core
vsock: add vsock_create_connected() called by transports
vsock: move vsock_insert_unbound() in the vsock_create()
hv_sock: set VMADDR_CID_HOST in the hvs_remote_addr_init()
vsock: add multi-transports support
vsock/vmci: register vmci_transport only when VMCI guest/host are
active
vsock: prevent transport modules unloading
vsock: fix bind() behaviour taking care of CID
vhost/vsock: refuse CID assigned to the guest->host transport
drivers/misc/vmw_vmci/vmci_driver.c | 67 +++++
drivers/misc/vmw_vmci/vmci_driver.h | 2 +
drivers/misc/vmw_vmci/vmci_guest.c | 2 +
drivers/misc/vmw_vmci/vmci_host.c | 7 +
drivers/vhost/vsock.c | 102 ++++---
include/linux/virtio_vsock.h | 18 +-
include/linux/vm_sockets.h | 15 -
include/linux/vmw_vmci_api.h | 2 +
include/net/af_vsock.h | 45 +--
include/net/vsock_addr.h | 2 +-
net/vmw_vsock/af_vsock.c | 382 ++++++++++++++++++------
net/vmw_vsock/hyperv_transport.c | 70 ++---
net/vmw_vsock/virtio_transport.c | 177 ++++++-----
net/vmw_vsock/virtio_transport_common.c | 166 +++++-----
net/vmw_vsock/vmci_transport.c | 140 ++++-----
net/vmw_vsock/vmci_transport.h | 3 -
net/vmw_vsock/vmci_transport_notify.h | 1 -
17 files changed, 679 insertions(+), 522 deletions(-)
delete mode 100644 include/linux/vm_sockets.h
--
2.21.0
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
