search for: notify_buffer_size

..., Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > @@ -140,18 +145,11 @@ struct vsock_transport { > struct vsock_transport_send_notify_data *); > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > struct vsock_transport_send_notify_data *); > + int (*notify_buffer_size)(struct vsock_sock *, u64 *); Is ->notify_buffer_size() called under lock_sock(sk)? If yes, please document it. > +static void vsock_update_buffer_size(struct vsock_sock *vsk, > + const struct vsock_transport *transport, > + u64 val) > +{ > + if (val > vsk-&g...

..., Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > @@ -140,18 +145,11 @@ struct vsock_transport { > struct vsock_transport_send_notify_data *); > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > struct vsock_transport_send_notify_data *); > + int (*notify_buffer_size)(struct vsock_sock *, u64 *); Is ->notify_buffer_size() called under lock_sock(sk)? If yes, please document it. > +static void vsock_update_buffer_size(struct vsock_sock *vsk, > + const struct vsock_transport *transport, > + u64 val) > +{ > + if (val > vsk-&g...

...7PM +0200, Stefano Garzarella wrote: > > @@ -140,18 +145,11 @@ struct vsock_transport { > > struct vsock_transport_send_notify_data *); > > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > > struct vsock_transport_send_notify_data *); > > + int (*notify_buffer_size)(struct vsock_sock *, u64 *); > > Is ->notify_buffer_size() called under lock_sock(sk)? If yes, please > document it. Yes, it is. I'll document it! > > > +static void vsock_update_buffer_size(struct vsock_sock *vsk, > > + const struct vsock_transport *tra...

...le the buffer_size sockopts in a > very similar way. > > In order to support multiple transports, this patch moves this handling in the > core to allow the user to change the options also if the socket is not yet > assigned to any transport. > > This patch also adds the '.notify_buffer_size' callback in the 'struct > virtio_transport' in order to inform the transport, when the buffer_size is > changed by the user. It is also useful to limit the 'buffer_size' requested (e.g. > virtio transports). > > Acked-by: Dexuan Cui <decui at microsoft.com&gt...

...o_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform the transport, when the buffer_size is changed by the user. It is also useful to limit the 'buffer_size' requested (e.g. virtio transports). Acked-by: Dexuan Cui <decui at microsoft.com> Signed-off-by: Stefano...

...o_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform the transport, when the buffer_size is changed by the user. It is also useful to limit the 'buffer_size' requested (e.g. virtio transports). Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drive...

...buffer_size(). > > Now the limit is only applied at socket init time. If the buffer size > > is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded. If > > that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE > > here? > > > > The .notify_buffer_size() should avoid this issue, since it allows the > transport to limit the buffer size requested after the initialization. > > But again the min set by the user can not be respected and in the > previous implementation we forced it to VIRTIO_VSOCK_MAX_BUF_SIZE. > > Now we don't...

...he same time. Before this series, vmci-transport supported this behavior but only using VMware hypervisor on L0, L1, etc. RFC: https://patchwork.ozlabs.org/cover/1168442/ RFC -> v1: - Added R-b/A-b from Dexuan and Stefan - Fixed comments and typos in several patches (Stefan) - Patch 7: changed .notify_buffer_size return to void (Stefan) - Added patch 8 to simplify the API exposed to the transports (Stefan) - Patch 11: + documented VSOCK_TRANSPORT_F_* flags (Stefan) + fixed vsock_assign_transport() when the socket is already assigned + moved features outside of struct vsock_transport, and used as p...

...he same time. Before this series, vmci-transport supported this behavior but only using VMware hypervisor on L0, L1, etc. RFC: https://patchwork.ozlabs.org/cover/1168442/ RFC -> v1: - Added R-b/A-b from Dexuan and Stefan - Fixed comments and typos in several patches (Stefan) - Patch 7: changed .notify_buffer_size return to void (Stefan) - Added patch 8 to simplify the API exposed to the transports (Stefan) - Patch 11: + documented VSOCK_TRANSPORT_F_* flags (Stefan) + fixed vsock_assign_transport() when the socket is already assigned + moved features outside of struct vsock_transport, and used as p...

...mci-transport supported this behavior but only > using VMware hypervisor on L0, L1, etc. > > RFC: https://patchwork.ozlabs.org/cover/1168442/ > RFC -> v1: > - Added R-b/A-b from Dexuan and Stefan > - Fixed comments and typos in several patches (Stefan) > - Patch 7: changed .notify_buffer_size return to void (Stefan) > - Added patch 8 to simplify the API exposed to the transports (Stefan) > - Patch 11: > + documented VSOCK_TRANSPORT_F_* flags (Stefan) > + fixed vsock_assign_transport() when the socket is already assigned > + moved features outside of struct vsock_tra...

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

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:

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