search for: hvs_remote_addr_init

...transport.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c index 4f47af2054dd..306310794522 100644 --- a/net/vmw_vsock/hyperv_transport.c +++ b/net/vmw_vsock/hyperv_transport.c @@ -186,7 +186,8 @@ static void hvs_remote_addr_init(struct sockaddr_vm *remote, static u32 host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT; struct sock *sk; - vsock_addr_init(remote, VMADDR_CID_ANY, VMADDR_PORT_ANY); + /* Remote peer is always the host */ + vsock_addr_init(remote, VMADDR_CID_HOST, VMADDR_PORT_ANY); while (1) { /* Wrap aro...

On Fri, Oct 04, 2019 at 12:04:46AM +0000, Dexuan Cui wrote: > > From: Stefano Garzarella <sgarzare at redhat.com> > > Sent: Friday, September 27, 2019 4:27 AM > > ... > > Patch 9 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. > > @Dexuan Could this change break anything? > > This patch looks good to me. > Thank you very much for your reviews! > > @D...

...guid_t *id) { return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(guid_t) - 4); @@ -367,6 +369,18 @@ static void hvs_open_connection(struct vmbus_channel *chan) new->sk_state = TCP_SYN_SENT; vnew = vsock_sk(new); + + hvs_addr_init(&vnew->local_addr, if_type); + hvs_remote_addr_init(&vnew->remote_addr, &vnew->local_addr); + + ret = vsock_assign_transport(vnew, vsock_sk(sk)); + /* Transport assigned (looking at remote_addr) must be the + * same where we received the request. + */ + if (ret || !hvs_check_transport(vnew)) { + sock_put(new); + goto out; +...

...guid_t *id) { return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(guid_t) - 4); @@ -366,6 +368,18 @@ static void hvs_open_connection(struct vmbus_channel *chan) new->sk_state = TCP_SYN_SENT; vnew = vsock_sk(new); + + hvs_addr_init(&vnew->local_addr, if_type); + hvs_remote_addr_init(&vnew->remote_addr, &vnew->local_addr); + + ret = vsock_assign_transport(vnew, vsock_sk(sk)); + /* Transport assigned (looking at remote_addr) must be the + * same where we received the request. + */ + if (ret || !hvs_check_transport(vnew)) { + sock_put(new); + goto out; +...

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

...h 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 8 patches are cleanups and preparations, maybe some of these can go regardless of this series. Patch 9 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. @Dexuan Could this change break anything? Patch 10 adds multi-transports support. RFC: - I'd like to move MODULE_ALIAS_NETPROTO(PF_VSOCK) to af_vsock.c. @Jorgen co...

...h 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 8 patches are cleanups and preparations, maybe some of these can go regardless of this series. Patch 9 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. @Dexuan Could this change break anything? Patch 10 adds multi-transports support. RFC: - I'd like to move MODULE_ALIAS_NETPROTO(PF_VSOCK) to af_vsock.c. @Jorgen co...

...Removed "vsock: add 'transport_hg' to handle g2h\h2g transports" patch - Added patch 12 to register vmci_transport only when VMCI guest/host are active 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 touch a little bit the vmci_transport and the vmci driver to register the vmci_transport only when there are active hos...

...Removed "vsock: add 'transport_hg' to handle g2h\h2g transports" patch - Added patch 12 to register vmci_transport only when VMCI guest/host are active 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 touch a little bit the vmci_transport and the vmci driver to register the vmci_transport only when there are active hos...

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in