All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Andra Paraschiv <andraprs@amazon.com>
Cc: netdev <netdev@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	David Duncan <davdunc@amazon.com>,
	Dexuan Cui <decui@microsoft.com>, Alexander Graf <graf@amazon.de>,
	Jorgen Hansen <jhansen@vmware.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
Date: Thu, 3 Dec 2020 09:21:55 +0000	[thread overview]
Message-ID: <20201203092155.GB687169@stefanha-x1.localdomain> (raw)
In-Reply-To: <20201201152505.19445-2-andraprs@amazon.com>

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-12-03  9:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 15:25 [PATCH net-next v1 0/3] vsock: Add flag field in the vsock address Andra Paraschiv
2020-12-01 15:25 ` [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure Andra Paraschiv
2020-12-01 16:09   ` Stefano Garzarella
2020-12-01 18:15     ` Paraschiv, Andra-Irina
2020-12-02  8:32       ` Stefano Garzarella
2020-12-03  9:21   ` Stefan Hajnoczi [this message]
2020-12-03 10:32     ` Paraschiv, Andra-Irina
2020-12-03 13:38       ` Stefano Garzarella
2020-12-03 14:04         ` Paraschiv, Andra-Irina
2020-12-01 15:25 ` [PATCH net-next v1 2/3] virtio_transport_common: Set sibling VMs flag on the receive path Andra Paraschiv
2020-12-01 16:22   ` Stefano Garzarella
2020-12-01 19:01     ` Paraschiv, Andra-Irina
2020-12-02  8:53       ` Stefano Garzarella
2020-12-01 15:25 ` [PATCH net-next v1 3/3] af_vsock: Assign the vsock transport considering the vsock address flag Andra Paraschiv
2020-12-01 16:23   ` Stefano Garzarella
2020-12-01 19:06     ` Paraschiv, Andra-Irina
2020-12-01 16:27 ` [PATCH net-next v1 0/3] vsock: Add flag field in the vsock address Stefano Garzarella
2020-12-01 18:02   ` Paraschiv, Andra-Irina
2020-12-02 13:37 ` Stefano Garzarella
2020-12-02 16:18   ` Paraschiv, Andra-Irina
2020-12-03  8:51     ` Stefano Garzarella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201203092155.GB687169@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=andraprs@amazon.com \
    --cc=davdunc@amazon.com \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=graf@amazon.de \
    --cc=jhansen@vmware.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sgarzare@redhat.com \
    --cc=vkuznets@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.