Messages in this thread | | | Subject | Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure | From | "Paraschiv, Andra-Irina" <> | Date | Thu, 3 Dec 2020 16:04:44 +0200 |
| |
On 03/12/2020 15:38, Stefano Garzarella wrote: > > 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).
Ok, then VMADDR_FLAG_TO_HOST it is. :) I also updated the commit messages / comments to reflect this more general angle, with one of the current use cases being guest to guest communication.
Thanks, Andra
> >> >> 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. >> >
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.
| |