search for: svm_cid

local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Cc: Stefan Hajnoczi <stefanha at redhat.com> Cc: stable at vger.kernel.org #4.8+ Signed-off-by: Peng Tao <bergwolf at gmail.com> --- drivers/vhost/vsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-...

local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Otherwise we end up resetting all connections to all guests. Cc: stable at vger.kernel.org [4.8+] Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Peng Tao <bergwolf at gmail.com> --- rese...

local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Cc: Stefan Hajnoczi <stefanha at redhat.com> Cc: stable at vger.kernel.org #4.8+ Signed-off-by: Peng Tao <bergwolf at gmail.com> --- drivers/vhost/vsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-...

local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Otherwise we end up resetting all connections to all guests. Cc: stable at vger.kernel.org [4.8+] Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Peng Tao <bergwolf at gmail.com> --- rese...

...le32_to_cpu(pkt->hdr.dst_cid), > + le64_to_cpu(pkt->hdr.dst_cid), > le32_to_cpu(pkt->hdr.dst_port), > - le32_to_cpu(pkt->hdr.src_cid), > + le64_to_cpu(pkt->hdr.src_cid), > le32_to_cpu(pkt->hdr.src_port)); Looking at sockaddr_vm, svm_cid is "unsigned int", 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_VSO...

...le32_to_cpu(pkt->hdr.dst_cid), > + le64_to_cpu(pkt->hdr.dst_cid), > le32_to_cpu(pkt->hdr.dst_port), > - le32_to_cpu(pkt->hdr.src_cid), > + le64_to_cpu(pkt->hdr.src_cid), > le32_to_cpu(pkt->hdr.src_port)); Looking at sockaddr_vm, svm_cid is "unsigned int", 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_VSO...

...p;vhost_vsock_lock); + return len; } @@ -236,18 +242,22 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk) int cnt = 0; LIST_HEAD(freeme); + spin_lock_bh(&vhost_vsock_lock); + /* Find the vhost_vsock according to guest context id */ - vsock = vhost_vsock_get(vsk->remote_addr.svm_cid); - if (!vsock) + vsock = __vhost_vsock_get(vsk->remote_addr.svm_cid); + if (!vsock) { + spin_unlock_bh(&vhost_vsock_lock); return -ENODEV; + } - spin_lock_bh(&vsock->send_pkt_list_lock); + spin_lock(&vsock->send_pkt_list_lock); list_for_each_entry_safe(pkt, n, &vso...

...p;vhost_vsock_lock); + return len; } @@ -236,18 +242,22 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk) int cnt = 0; LIST_HEAD(freeme); + spin_lock_bh(&vhost_vsock_lock); + /* Find the vhost_vsock according to guest context id */ - vsock = vhost_vsock_get(vsk->remote_addr.svm_cid); - if (!vsock) + vsock = __vhost_vsock_get(vsk->remote_addr.svm_cid); + if (!vsock) { + spin_unlock_bh(&vhost_vsock_lock); return -ENODEV; + } - spin_lock_bh(&vsock->send_pkt_list_lock); + spin_lock(&vsock->send_pkt_list_lock); list_for_each_entry_safe(pkt, n, &vso...

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). Stefan: Do you think we should have a single application or is better to split it in single tests (e.g.

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

...@@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr) * like AF_INET prevents binding to a non-local IP address (in most * cases), we only allow binding to the local CID. */ - cid = transport->get_local_cid(); + cid = vsk->transport->get_local_cid(); if (addr->svm_cid != cid && addr->svm_cid != VMADDR_CID_ANY) return -EADDRNOTAVAIL; @@ -586,6 +588,7 @@ struct sock *__vsock_create(struct net *net, sk->sk_type = type; vsk = vsock_sk(sk); + vsk->transport = transport_single; vsock_addr_init(&vsk->local_addr, VMADDR_CID_ANY, VMA...

...t vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk) +{ + const struct vsock_transport *new_transport; + struct sock *sk = sk_vsock(vsk); + + switch (sk->sk_type) { + case SOCK_DGRAM: + new_transport = transport_dgram; + break; + case SOCK_STREAM: + if (vsk->remote_addr.svm_cid > VMADDR_CID_HOST) + new_transport = transport_h2g; + else + new_transport = transport_g2h; + break; + default: + return -ESOCKTNOSUPPORT; + } + + if (vsk->transport) { + if (vsk->transport == new_transport) + return 0; + + vsk->transport->release(vsk); + vsk->transpor...

...@@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr) * like AF_INET prevents binding to a non-local IP address (in most * cases), we only allow binding to the local CID. */ - cid = transport->get_local_cid(); + cid = vsk->transport->get_local_cid(); if (addr->svm_cid != cid && addr->svm_cid != VMADDR_CID_ANY) return -EADDRNOTAVAIL; @@ -586,6 +588,7 @@ struct sock *__vsock_create(struct net *net, sk->sk_type = type; vsk = vsock_sk(sk); + vsk->transport = transport_single; vsock_addr_init(&vsk->local_addr, VMADDR_CID_ANY, VMA...

...{ + struct sock *sk = sk_vsock(vsk); + /* RFC-TODO: should vsk->transport be already assigned? + * How to handle? + */ + WARN_ON(vsk->transport); + + switch (sk->sk_type) { + case SOCK_DGRAM: + vsk->transport = transport_dgram; + break; + case SOCK_STREAM: + if (vsk->remote_addr.svm_cid > VMADDR_CID_HOST) + vsk->transport = transport_h2g; + else + vsk->transport = transport_g2h; + break; + default: + return -ESOCKTNOSUPPORT; + } + + if (!vsk->transport) + return -ENODEV; + + return vsk->transport->init(vsk, psk); +} +EXPORT_SYMBOL_GPL(vsock_assign_transpo...

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

...isable Nagle's algorithm on the socket, but don't fail. */ static void disable_nagle (int sock) @@ -118,6 +122,24 @@ STATE_MACHINE { SET_NEXT_STATE (%^CONNECT.START); return 0; + CONNECT_VSOCK.START: +#ifdef AF_VSOCK + struct sockaddr_vm svm = { + .svm_family = AF_VSOCK, + .svm_cid = h->svm_cid, + .svm_port = h->svm_port, + }; + const socklen_t len = sizeof svm; + + memcpy (&h->connaddr, &svm, len); + h->connaddrlen = len; + SET_NEXT_STATE (%^CONNECT.START); + return 0; +#else + set_error (ENOTSUP, "AF_VSOCK protocol is not supported");...

...il. */ > static void > disable_nagle (int sock) > @@ -118,6 +122,24 @@ STATE_MACHINE { > SET_NEXT_STATE (%^CONNECT.START); > return 0; > > + CONNECT_VSOCK.START: > +#ifdef AF_VSOCK > + struct sockaddr_vm svm = { > + .svm_family = AF_VSOCK, > + .svm_cid = h->svm_cid, > + .svm_port = h->svm_port, > + }; Are there scenarios (mismatch in kernel vs. headers compiled against, for instance) where compilation says AF_VSOCK exists but where all attempts at vsock fail? If so, is there anything that we should check dynamically, rather t...

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012