search for: ioctl_vm_sockets_get_local_cid

...e user uses the local guest CID, it works, but if > it uses the HOST_CID, the packet will go to the L0. > > If we are in L0, it could be simple, because we can simply check if G2H > is not loaded, so any packet to CID_HOST, is host loopback. > > I think that if the user uses the IOCTL_VM_SOCKETS_GET_LOCAL_CID, to set > the dest CID for the loopback, it works in both cases because we return the > HOST_CID in L0, and always the guest CID in L1, also if a H2G is loaded to > handle the L2. > > Maybe we should document this in the man page. Yeah, it seems like a good idea to flesh out the ro...

...SOCK 287 /* IPX options */ #define IPX_TYPE 1 diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index c60ca33eac594..ed07181d4eff9 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -191,4 +191,21 @@ struct sockaddr_vm { #define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9) +/* MSG_ZEROCOPY notifications are encoded in the standard error format, + * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in + * kernel source tree for more details. + */ + +/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing...

...SOCK 287 /* IPX options */ #define IPX_TYPE 1 diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index c60ca33eac594..ed07181d4eff9 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -191,4 +191,21 @@ struct sockaddr_vm { #define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9) +/* MSG_ZEROCOPY notifications are encoded in the standard error format, + * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in + * kernel source tree for more details. + */ + +/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing...

...SOCK 287 /* IPX options */ #define IPX_TYPE 1 diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index c60ca33eac594..ed07181d4eff9 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -191,4 +191,21 @@ struct sockaddr_vm { #define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9) +/* MSG_ZEROCOPY notifications are encoded in the standard error format, + * sock_extended_err. See Documentation/networking/msg_zerocopy.rst in + * kernel source tree for more details. + */ + +/* 'cmsg_level' field value of 'struct cmsghdr' for notification parsing...

...+ * of this structure should be exactly the same as that of struct sockaddr. */ struct sockaddr_vm { - sa_family_t svm_family; + __kernel_sa_family_t svm_family; unsigned short svm_reserved1; unsigned int svm_port; unsigned int svm_cid; @@ -156,8 +153,4 @@ struct sockaddr_vm { #define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9) -#if defined(__KERNEL__) -int vm_sockets_get_local_cid(void); -#endif - -#endif +#endif /* _UAPI_VM_SOCKETS_H */ -- 1.7.4.1

...+ * of this structure should be exactly the same as that of struct sockaddr. */ struct sockaddr_vm { - sa_family_t svm_family; + __kernel_sa_family_t svm_family; unsigned short svm_reserved1; unsigned int svm_port; unsigned int svm_cid; @@ -156,8 +153,4 @@ struct sockaddr_vm { #define IOCTL_VM_SOCKETS_GET_LOCAL_CID _IO(7, 0xb9) -#if defined(__KERNEL__) -int vm_sockets_get_local_cid(void); -#endif - -#endif +#endif /* _UAPI_VM_SOCKETS_H */ -- 1.7.4.1

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Monday, November 11, 2019 6:18 PM > To: Jorgen Hansen <jhansen at vmware.com> > Subject: Re: [PATCH net-next 11/14] vsock: add multi-transports support > > On Mon, Nov 11, 2019 at 01:53:39PM +0000, Jorgen Hansen wrote: > > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > >

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Monday, November 11, 2019 6:18 PM > To: Jorgen Hansen <jhansen at vmware.com> > Subject: Re: [PATCH net-next 11/14] vsock: add multi-transports support > > On Mon, Nov 11, 2019 at 01:53:39PM +0000, Jorgen Hansen wrote: > > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > >

...@ -1650,6 +1669,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, sk = sock->sk; vsk = vsock_sk(sk); + transport = vsk->transport; err = 0; lock_sock(sk); @@ -1864,7 +1884,7 @@ static long vsock_dev_do_ioctl(struct file *filp, switch (cmd) { case IOCTL_VM_SOCKETS_GET_LOCAL_CID: - if (put_user(transport->get_local_cid(), p) != 0) + if (put_user(transport_single->get_local_cid(), p) != 0) retval = -EFAULT; break; @@ -1911,7 +1931,7 @@ int __vsock_core_init(const struct vsock_transport *t, struct module *owner) if (err) return err; - if (transport) {...

...) So if we are in a L1 and the user uses the local guest CID, it works, but if it uses the HOST_CID, the packet will go to the L0. If we are in L0, it could be simple, because we can simply check if G2H is not loaded, so any packet to CID_HOST, is host loopback. I think that if the user uses the IOCTL_VM_SOCKETS_GET_LOCAL_CID, to set the dest CID for the loopback, it works in both cases because we return the HOST_CID in L0, and always the guest CID in L1, also if a H2G is loaded to handle the L2. Maybe we should document this in the man page. But I have a question: Does vmci support the host loopback? I've tried,...

...@ -1658,6 +1677,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, sk = sock->sk; vsk = vsock_sk(sk); + transport = vsk->transport; err = 0; lock_sock(sk); @@ -1872,7 +1892,7 @@ static long vsock_dev_do_ioctl(struct file *filp, switch (cmd) { case IOCTL_VM_SOCKETS_GET_LOCAL_CID: - if (put_user(transport->get_local_cid(), p) != 0) + if (put_user(transport_single->get_local_cid(), p) != 0) retval = -EFAULT; break; @@ -1919,7 +1939,7 @@ int __vsock_core_init(const struct vsock_transport *t, struct module *owner) if (err) return err; - if (transport) {...

v1 was discussed here: https://www.redhat.com/archives/libguestfs/2019-October/thread.html#00100 v2: - Bind to VMADDR_CID_ANY (instead of HOST) and update the documentation accordingly. - Don't bother with SOCK_CLOEXEC fallback path that can never be used. Rich.

...ut(sk); + return ret; + } + } + + vsock_insert_unbound(vsk); return 0; } @@ -1926,11 +2003,20 @@ static long vsock_dev_do_ioctl(struct file *filp, unsigned int cmd, void __user *ptr) { u32 __user *p = ptr; + u32 cid = VMADDR_CID_ANY; int retval = 0; switch (cmd) { case IOCTL_VM_SOCKETS_GET_LOCAL_CID: - if (put_user(transport_single->get_local_cid(), p) != 0) + /* To be compatible with the VMCI behavior, we prioritize the + * guest CID instead of well-know host CID (VMADDR_CID_HOST). + */ + if (transport_g2h) + cid = transport_g2h->get_local_cid(); + else if (transport_h2g) +...

...ut(sk); + return ret; + } + } + + vsock_insert_unbound(vsk); return 0; } @@ -1912,11 +1985,20 @@ static long vsock_dev_do_ioctl(struct file *filp, unsigned int cmd, void __user *ptr) { u32 __user *p = ptr; + u32 cid = VMADDR_CID_ANY; int retval = 0; switch (cmd) { case IOCTL_VM_SOCKETS_GET_LOCAL_CID: - if (put_user(transport_single->get_local_cid(), p) != 0) + /* To be compatible with the VMCI behavior, we prioritize the + * guest CID instead of well-know host CID (VMADDR_CID_HOST). + */ + if (transport_g2h) + cid = transport_g2h->get_local_cid(); + else if (transport_h2g) +...

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

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