search for: detach_sub_id

...in_unlock_bh(&trans->lock); } static void vmci_transport_qp_resumed_cb(u32 sub_id, @@ -1181,7 +1155,7 @@ vmci_transport_recv_connecting_server(struct sock *listener, */ err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH, vmci_transport_peer_detach_cb, - pending, &detach_sub_id); + vmci_trans(vpending), &detach_sub_id); if (err < VMCI_SUCCESS) { vmci_transport_send_reset(pending, pkt); err = vmci_transport_error_to_vsock_error(err); @@ -1321,7 +1295,6 @@ vmci_transport_recv_connecting_client(struct sock *sk, || vmci_trans(vsk)->qpair...

...in_unlock_bh(&trans->lock); } static void vmci_transport_qp_resumed_cb(u32 sub_id, @@ -1181,7 +1155,7 @@ vmci_transport_recv_connecting_server(struct sock *listener, */ err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH, vmci_transport_peer_detach_cb, - pending, &detach_sub_id); + vmci_trans(vpending), &detach_sub_id); if (err < VMCI_SUCCESS) { vmci_transport_send_reset(pending, pkt); err = vmci_transport_error_to_vsock_error(err); @@ -1321,7 +1295,6 @@ vmci_transport_recv_connecting_client(struct sock *sk, || vmci_trans(vsk)->qpair...

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

* * * 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

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

...mw_vsock/vmci_transport.h > +++ b/net/vmw_vsock/vmci_transport.h > @@ -108,9 +108,6 @@ struct vmci_transport { > struct vmci_qp *qpair; > u64 produce_size; > u64 consume_size; > - u64 queue_pair_size; > - u64 queue_pair_min_size; > - u64 queue_pair_max_size; > u32 detach_sub_id; > union vmci_transport_notify notify; > const struct vmci_transport_notify_ops *notify_ops; > -- > 2.21.0 Reviewed-by: Jorgen Hansen <jhansen at vmware.com>

...1ca1e8640b31..b7b072194282 100644 --- a/net/vmw_vsock/vmci_transport.h +++ b/net/vmw_vsock/vmci_transport.h @@ -108,9 +108,6 @@ struct vmci_transport { struct vmci_qp *qpair; u64 produce_size; u64 consume_size; - u64 queue_pair_size; - u64 queue_pair_min_size; - u64 queue_pair_max_size; u32 detach_sub_id; union vmci_transport_notify notify; const struct vmci_transport_notify_ops *notify_ops; -- 2.21.0

...1ca1e8640b31..b7b072194282 100644 --- a/net/vmw_vsock/vmci_transport.h +++ b/net/vmw_vsock/vmci_transport.h @@ -108,9 +108,6 @@ struct vmci_transport { struct vmci_qp *qpair; u64 produce_size; u64 consume_size; - u64 queue_pair_size; - u64 queue_pair_min_size; - u64 queue_pair_max_size; u32 detach_sub_id; union vmci_transport_notify notify; const struct vmci_transport_notify_ops *notify_ops; -- 2.21.0

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using