search for: g2h

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 handl...

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 w...

...>> > > > > 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 >> > &g...

...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 vmci an...

...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 vmci an...

...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 vmci an...

...ajor 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...

...ajor 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...

...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 previo...

v2: - style fixes [Dave] - removed RCU sync and changed 'the_vsock_loopback' in a global static variable [Stefan] - use G2H transport when local transport is not loaded and remote cid is VMADDR_CID_LOCAL [Stefan] - rebased on net-next v1: https://patchwork.kernel.org/cover/11251735/ This series introduces a new transport (vsock_loopback) to handle local communication. This could be useful to test vsock core itself...

...ransports 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). H...

...ransports 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). H...

...e > > > application will use the CID_HOST as address, but if we are in a nested > > > VM environment we are in trouble. > > > > If both src and dst CID are CID_HOST, we should be fairly sure that this > > Is host loopback, no? If src is anything else, we would do G2H. > > > > The problem is that we don't know the src until we assign a transport > looking at the dst. (or if the user bound the socket to CID_HOST before > the connect(), but it is not very common) > > So if we are in a L1 and the user uses the local guest CID, it works...

...tions from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in different network namespaces - partition VMs between VMMs or at finer granularity This preliminary implementation provides the following behavior: - packets received from the host (received by G2H transports) are assigned to the default netns (init_net) - packets received from the guest (received by H2G - vhost-vsock) are assigned to the netns of the process that opens /dev/vhost-vsock (usually the VMM, qemu in my tests, opens the /dev/vhost-vsock) - for vmci I need some suggestion...

...tions from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in different network namespaces - partition VMs between VMMs or at finer granularity This preliminary implementation provides the following behavior: - packets received from the host (received by G2H transports) are assigned to the default netns (init_net) - packets received from the guest (received by H2G - vhost-vsock) are assigned to the netns of the process that opens /dev/vhost-vsock (usually the VMM, qemu in my tests, opens the /dev/vhost-vsock) - for vmci I need some suggestion...

...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 we r...

> 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 alre...

> 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 alre...

...using the same ports > with CID_ANY > - assign the same CID of VMs running in different network namespaces > - partition VMs between VMMs or at finer granularity > > This preliminary implementation provides the following behavior: > - packets received from the host (received by G2H transports) are > assigned to the default netns (init_net) > - packets received from the guest (received by H2G - vhost-vsock) are > assigned to the netns of the process that opens /dev/vhost-vsock > (usually the VMM, qemu in my tests, opens the /dev/vhost-vsock) > - for vm...

...t; > > > 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 > >...