search for: remote_cid

On Tue, Nov 19, 2019 at 12:01:20PM +0100, Stefano Garzarella wrote: > @@ -420,9 +436,10 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk) > new_transport = transport_dgram; > break; > case SOCK_STREAM: > - if (remote_cid <= VMADDR_CID_HOST || > - (transport_g2h && > - remote_cid == transport_g2h->get_local_cid())) > + if (vsock_use_local_transport(remote_cid)) > + new_transport = transport_local; > + else if (remote_cid == VMADDR_CID_HOST || > + remote_cid == VMADDR...

...ot;, do we really want 64 bit here? > if (!pkt) > return -ENOMEM; > @@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk, > struct virtio_vsock_pkt_info info = { > .op = VIRTIO_VSOCK_OP_RESPONSE, > .type = VIRTIO_VSOCK_TYPE_STREAM, > - .remote_cid = le32_to_cpu(pkt->hdr.src_cid), > + .remote_cid = le64_to_cpu(pkt->hdr.src_cid), > .remote_port = le32_to_cpu(pkt->hdr.src_port), > .reply = true, > }; > @@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt) > chil...

...ot;, do we really want 64 bit here? > if (!pkt) > return -ENOMEM; > @@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk, > struct virtio_vsock_pkt_info info = { > .op = VIRTIO_VSOCK_OP_RESPONSE, > .type = VIRTIO_VSOCK_TYPE_STREAM, > - .remote_cid = le32_to_cpu(pkt->hdr.src_cid), > + .remote_cid = le64_to_cpu(pkt->hdr.src_cid), > .remote_port = le32_to_cpu(pkt->hdr.src_port), > .reply = true, > }; > @@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt) > chil...

...remote_addr.svm_cid > VMADDR_CID_HOST) > + new_transport = transport_h2g; > + else > + new_transport = transport_g2h; I just noticed that this break the loopback in the guest. As a fix, we should use 'transport_g2h' when remote_cid <= VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. To do that we also need to avoid that L2 guests can have the same CID of L1. For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() @Jorgen: for vmci we need to do the same? or it is guaranteed, since it's...

...remote_addr.svm_cid > VMADDR_CID_HOST) > + new_transport = transport_h2g; > + else > + new_transport = transport_g2h; I just noticed that this break the loopback in the guest. As a fix, we should use 'transport_g2h' when remote_cid <= VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. To do that we also need to avoid that L2 guests can have the same CID of L1. For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() @Jorgen: for vmci we need to do the same? or it is guaranteed, since it's...

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

...le64_to_cpu(pkt->hdr.src_cid), le32_to_cpu(pkt->hdr.src_port)); if (!pkt) return -ENOMEM; @@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk, struct virtio_vsock_pkt_info info = { .op = VIRTIO_VSOCK_OP_RESPONSE, .type = VIRTIO_VSOCK_TYPE_STREAM, - .remote_cid = le32_to_cpu(pkt->hdr.src_cid), + .remote_cid = le64_to_cpu(pkt->hdr.src_cid), .remote_port = le32_to_cpu(pkt->hdr.src_port), .reply = true, }; @@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt) child->sk_state = SS_CONNECTED;...

...nclude/linux/virtio_vsock.h @@ -48,6 +48,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_hdr hdr; struct work_struct work; struct list_head list; + struct vsock_sock *vsk; void *buf; u32 len; u32 off; @@ -56,6 +57,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_pkt_info { u32 remote_cid, remote_port; + struct vsock_sock *vsk; struct msghdr *msg; u32 pkt_len; u16 type; diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index a53b3a1..cc1eeb5 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_co...

...@ -48,6 +48,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_hdr hdr; struct work_struct work; struct list_head list; + void *cancel_token; /* only used for cancellation */ void *buf; u32 len; u32 off; @@ -56,6 +57,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_pkt_info { u32 remote_cid, remote_port; + struct vsock_sock *vsk; struct msghdr *msg; u32 pkt_len; u16 type; diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index a53b3a1..ef94eb8 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_co...

...@ -48,6 +48,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_hdr hdr; struct work_struct work; struct list_head list; + void *cancel_token; /* only used for cancellation */ void *buf; u32 len; u32 off; @@ -56,6 +57,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_pkt_info { u32 remote_cid, remote_port; + struct vsock_sock *vsk; struct msghdr *msg; u32 pkt_len; u16 type; diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index a53b3a1..ef94eb8 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_co...

...@ -48,6 +48,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_hdr hdr; struct work_struct work; struct list_head list; + void *cancel_token; /* only used for cancellation */ void *buf; u32 len; u32 off; @@ -56,6 +57,7 @@ struct virtio_vsock_pkt { struct virtio_vsock_pkt_info { u32 remote_cid, remote_port; + struct vsock_sock *vsk; struct msghdr *msg; u32 pkt_len; u16 type; diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 849c4ad..ab505f1 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_co...

...R_CID_HOST) > > + new_transport = transport_h2g; > > + else > > + new_transport = transport_g2h; > > I just noticed that this break the loopback in the guest. > As a fix, we should use 'transport_g2h' when remote_cid <= > VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. > > To do that we also need to avoid that L2 guests can have the same CID of L1. > For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() > > @Jorgen: for vmci we need to do the same? or it...

...struct vsock_sock *psk) >> > > > > >> > > > > switch (sk->sk_type) { >> > > > > case SOCK_DGRAM: >> > > > > - new_transport = transport_dgram; >> > > > > + new_transport = vsock_dgram_lookup_transport(remote_cid, >> > > > > + remote_flags); >> > > > >> > > > I'm a little bit confused about this: >> > > > 1) Let's create SOCK_DGRAM socket using vsock_create() >> > > > 2) for SOCK_DGRAM it calls 'vsock_assign...

Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent even though the connection is considered a failure, which can confuse applications with unwanted false connect attempt. The patchset enables vsock (both host and guest) to cancel queued packets when a

Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent even though the connection is considered a failure, which can confuse applications with unwanted false connect attempt. The patchset enables vsock (both host and guest) to cancel queued packets when a

...gt;>> bool reply; >>> }; >>> +struct virtio_vsock_buf { >>> + struct list_head list; >>> + void *addr; >>> + u32 len; >>> + u32 off; >>> +}; >>> + >>> struct virtio_vsock_pkt_info { >>> u32 remote_cid, remote_port; >>> struct vsock_sock *vsk; >>> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c >>> index 15eb5d3d4750..af1d2ce12f54 100644 >>> --- a/net/vmw_vsock/virtio_transport.c >>> +++ b/net/vmw_vsock/virtio_trans...

...gt;>> bool reply; >>> }; >>> +struct virtio_vsock_buf { >>> + struct list_head list; >>> + void *addr; >>> + u32 len; >>> + u32 off; >>> +}; >>> + >>> struct virtio_vsock_pkt_info { >>> u32 remote_cid, remote_port; >>> struct vsock_sock *vsk; >>> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c >>> index 15eb5d3d4750..af1d2ce12f54 100644 >>> --- a/net/vmw_vsock/virtio_transport.c >>> +++ b/net/vmw_vsock/virtio_trans...

Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent even though the connection is considered a failure, which can confuse applications with unwanted false connect attempt. The patchset enables vsock (both host and guest) to cancel queued packets when a

Currently, if a connect call fails on a signal or timeout (e.g., guest is still in the process of starting up), we'll just return to caller and leave the connect packet queued and they are sent even though the connection is considered a failure, which can confuse applications with unwanted false connect attempt. The patchset enables vsock (both host and guest) to cancel queued packets when a

...k *vsock; + struct scatterlist hdr, buf, *sgs[2]; + struct virtqueue *vq; + u32 pkt_len = info->pkt_len; + DEFINE_WAIT(wait); + + vsock = virtio_vsock_get(); + if (!vsock) + return -ENODEV; + + src_cid = virtio_transport_get_local_cid(); + src_port = vsk->local_addr.svm_port; + if (!info->remote_cid) { + dst_cid = vsk->remote_addr.svm_cid; + dst_port = vsk->remote_addr.svm_port; + } else { + dst_cid = info->remote_cid; + dst_port = info->remote_port; + } + + trans = vsk->trans; + vq = vsock->vqs[VSOCK_VQ_TX]; + + if (pkt_len > VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE) + pkt_l...