Messages in this thread | | | Date | Thu, 3 Dec 2020 14:38:07 +0100 | From | Stefano Garzarella <> | Subject | Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure |
| |
On Thu, Dec 03, 2020 at 12:32:08PM +0200, Paraschiv, Andra-Irina wrote: > > >On 03/12/2020 11:21, Stefan Hajnoczi wrote: >>On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: >>>vsock enables communication between virtual machines and the host they >>>are running on. With the multi transport support (guest->host and >>>host->guest), nested VMs can also use vsock channels for communication. >>> >>>In addition to this, by default, all the vsock packets are forwarded to >>>the host, if no host->guest transport is loaded. This behavior can be >>>implicitly used for enabling vsock communication between sibling VMs. >>> >>>Add a flag field in the vsock address data structure that can be used to >>>explicitly mark the vsock connection as being targeted for a certain >>>type of communication. This way, can distinguish between nested VMs and >>>sibling VMs use cases and can also setup them at the same time. Till >>>now, could either have nested VMs or sibling VMs at a time using the >>>vsock communication stack. >>> >>>Use the already available "svm_reserved1" field and mark it as a flag >>>field instead. This flag can be set when initializing the vsock address >>>variable used for the connect() call. >>> >>>Signed-off-by: Andra Paraschiv <andraprs@amazon.com> >>>--- >>> include/uapi/linux/vm_sockets.h | 18 +++++++++++++++++- >>> 1 file changed, 17 insertions(+), 1 deletion(-) >>> >>>diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h >>>index fd0ed7221645d..58da5a91413ac 100644 >>>--- a/include/uapi/linux/vm_sockets.h >>>+++ b/include/uapi/linux/vm_sockets.h >>>@@ -114,6 +114,22 @@ >>> #define VMADDR_CID_HOST 2 >>>+/* This sockaddr_vm flag value covers the current default use case: >>>+ * local vsock communication between guest and host and nested VMs setup. >>>+ * In addition to this, implicitly, the vsock packets are forwarded to the host >>>+ * if no host->guest vsock transport is set. >>>+ */ >>>+#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x0000 >>>+ >>>+/* Set this flag value in the sockaddr_vm corresponding field if the vsock >>>+ * channel needs to be setup between two sibling VMs running on the same host. >>>+ * This way can explicitly distinguish between vsock channels created for nested >>>+ * VMs (or local communication between guest and host) and the ones created for >>>+ * sibling VMs. And vsock channels for multiple use cases (nested / sibling VMs) >>>+ * can be setup at the same time. >>>+ */ >>>+#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001 >>vsock has the h2g and g2h concept. It would be more general to call this >>flag VMADDR_FLAG_G2H or less cryptically VMADDR_FLAG_TO_HOST.
I agree, VMADDR_FLAG_TO_HOST is more general and it's clearer that is up to the host where to forward the packet (sibling if supported, or whatever).
Thanks, Stefano
> >Thanks for the feedback, Stefan. > >I can update the naming to be more general, such as "_TO_HOST", and >keep the use cases (e.g. guest <-> host / nested / sibling VMs >communication) mention in the comments so that would relate more to >the motivation behind it. > >Andra > >> >>That way it just tells the driver in which direction to send packets >>without implying that sibling communication is possible (it's not >>allowed by default on any transport). >> >>I don't have a strong opinion on this but wanted to suggest the idea. >> >>Stefan > > > > >Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. >
| |