search for: h2g

On Fri, Sep 27, 2019 at 01:27:01PM +0200, Stefano Garzarella wrote: > VMCI transport provides both g2h and h2g behaviors in a single > transport. > We are able to set (or not) the g2h behavior, detecting if we > are in a VMware guest (or not), but the h2g feature is always set. > This prevents to load other h2g transports while we are in a > VMware guest. In the vhost_vsock.ko case we only r...

VMCI transport provides both g2h and h2g behaviors in a single transport. We are able to set (or not) the g2h behavior, detecting if we are in a VMware guest (or not), but the h2g feature is always set. This prevents to load other h2g transports while we are in a VMware guest. This patch adds a new 'transport_hg' to handle this c...

...wrote: >> > > > > This patch adds support for multi-transport datagrams. >> > > > > >> > > > > This includes: >> > > > > - Per-packet lookup of transports when using sendto(sockaddr_vm) >> > > > > - Selecting H2G or G2H transport using VMADDR_FLAG_TO_HOST and CID in >> > > > > sockaddr_vm >> > > > > - rename VSOCK_TRANSPORT_F_DGRAM to VSOCK_TRANSPORT_F_DGRAM_FALLBACK >> > > > > - connect() now assigns the transport for (similar to connectible >>...

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > > To allow other transports to be loaded with vmci_transport, > we register the vmci_transport as G2H or H2G only when a VMCI guest > or host is active. > > To do that, this patch adds a callback registered in the vmci driver > that will be called when a new host or guest become active. > This callback will register the vmci_transport in the VSOCK core. > If the transport is already reg...

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > > To allow other transports to be loaded with vmci_transport, > we register the vmci_transport as G2H or H2G only when a VMCI guest > or host is active. > > To do that, this patch adds a callback registered in the vmci driver > that will be called when a new host or guest become active. > This callback will register the vmci_transport in the VSOCK core. > If the transport is already reg...

...0, Jorgen Hansen wrote: > > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > > Sent: Wednesday, October 23, 2019 11:56 AM > > > > > > To allow other transports to be loaded with vmci_transport, > > > we register the vmci_transport as G2H or H2G only when a VMCI guest > > > or host is active. > > > > > > To do that, this patch adds a callback registered in the vmci driver > > > that will be called when a new host or guest become active. > > > This callback will register the vmci_transport in the...

...gt; Major changes: > > > - vsock core module can be loaded regardless of the transports > > > - vsock_core_init() and vsock_core_exit() are renamed to > > > vsock_core_register() and vsock_core_unregister() > > > - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) > > > to identify which directions the transport can handle and if it's > > > support DGRAM (only vmci) > > > - each stream socket is assigned to a transport when the remote CID > > > is set (during the connect() or when we receive a connec...

...gt; Major changes: > > > - vsock core module can be loaded regardless of the transports > > > - vsock_core_init() and vsock_core_exit() are renamed to > > > vsock_core_register() and vsock_core_unregister() > > > - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) > > > to identify which directions the transport can handle and if it's > > > support DGRAM (only vmci) > > > - each stream socket is assigned to a transport when the remote CID > > > is set (during the connect() or when we receive a connec...

...2019 at 04:27:28PM +0000, Jorgen Hansen wrote: > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > Sent: Wednesday, October 23, 2019 11:56 AM > > > > To allow other transports to be loaded with vmci_transport, > > we register the vmci_transport as G2H or H2G only when a VMCI guest > > or host is active. > > > > To do that, this patch adds a callback registered in the vmci driver > > that will be called when a new host or guest become active. > > This callback will register the vmci_transport in the VSOCK core. > > I...

...est transports at the same time. > > Major changes: > - vsock core module can be loaded regardless of the transports > - vsock_core_init() and vsock_core_exit() are renamed to > vsock_core_register() and vsock_core_unregister() > - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) > to identify which directions the transport can handle and if it's > support DGRAM (only vmci) > - each stream socket is assigned to a transport when the remote CID > is set (during the connect() or when we receive a connection request > on a listener socket...

...est transports at the same time. > > Major changes: > - vsock core module can be loaded regardless of the transports > - vsock_core_init() and vsock_core_exit() are renamed to > vsock_core_register() and vsock_core_unregister() > - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) > to identify which directions the transport can handle and if it's > support DGRAM (only vmci) > - each stream socket is assigned to a transport when the remote CID > is set (during the connect() or when we receive a connection request > on a listener socket...

...gt; > > > - vsock core module can be loaded regardless of the transports > > > > - vsock_core_init() and vsock_core_exit() are renamed to > > > > vsock_core_register() and vsock_core_unregister() > > > > - vsock_core_register() has a feature parameter (H2G, G2H, DGRAM) > > > > to identify which directions the transport can handle and if it's > > > > support DGRAM (only vmci) > > > > - each stream socket is assigned to a transport when the remote CID > > > > is set (during the connect() or when...

...*' param to vsock_core_get_transport() vsock: handle buffer_size sockopts in the core 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: add 'transport_hg' to handle g2h\h2g transports vsock: prevent transport modules unloading vsock: fix bind() behaviour taking care of CID drivers/vhost/vsock.c | 96 +++--- include/linux/virtio_vsock.h | 18 +- include/linux/vm_sockets.h | 15 - include/net/af_vsock.h...

...*' param to vsock_core_get_transport() vsock: handle buffer_size sockopts in the core 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: add 'transport_hg' to handle g2h\h2g transports vsock: prevent transport modules unloading vsock: fix bind() behaviour taking care of CID drivers/vhost/vsock.c | 96 +++--- include/linux/virtio_vsock.h | 18 +- include/linux/vm_sockets.h | 15 - include/net/af_vsock.h...

...eir applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmc...

...eir applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmc...

...diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c > > > index cc8659838bf2..c9e5bad59dc1 100644 > > > --- a/net/vmw_vsock/af_vsock.c > > > +++ b/net/vmw_vsock/af_vsock.c > > > @@ -136,6 +136,8 @@ static const struct vsock_transport > *transport_h2g; > > > static const struct vsock_transport *transport_g2h; > > > /* Transport used for DGRAM communication */ > > > static const struct vsock_transport *transport_dgram; > > > +/* Transport used for local communication */ > > > +static const struct vs...

...diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c > > > index cc8659838bf2..c9e5bad59dc1 100644 > > > --- a/net/vmw_vsock/af_vsock.c > > > +++ b/net/vmw_vsock/af_vsock.c > > > @@ -136,6 +136,8 @@ static const struct vsock_transport > *transport_h2g; > > > static const struct vsock_transport *transport_g2h; > > > /* Transport used for DGRAM communication */ > > > static const struct vsock_transport *transport_dgram; > > > +/* Transport used for local communication */ > > > +static const struct vs...

...eir applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmc...

...if G2H > is not loaded, so any packet to CID_HOST, is host loopback. > > I think that if the user uses the IOCTL_VM_SOCKETS_GET_LOCAL_CID, to set > the dest CID for the loopback, it works in both cases because we return the > HOST_CID in L0, and always the guest CID in L1, also if a H2G is loaded to > handle the L2. > > Maybe we should document this in the man page. Yeah, it seems like a good idea to flesh out the routing behavior for nested VMs in the man page. > > But I have a question: Does vmci support the host loopback? > I've tried, and it seems not...