From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D5CAC28D1E for ; Thu, 6 Jun 2019 10:09:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 482F220684 for ; Thu, 6 Jun 2019 10:09:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727968AbfFFKJS (ORCPT ); Thu, 6 Jun 2019 06:09:18 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:38900 "EHLO mail-wm1-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727846AbfFFKJS (ORCPT ); Thu, 6 Jun 2019 06:09:18 -0400 Received: by mail-wm1-f43.google.com with SMTP id t5so1777906wmh.3 for ; Thu, 06 Jun 2019 03:09:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=FZ1QMnc0d0X8al9RBTmx1RL+tFKEs14dZ4ijHmJImUQ=; b=D8yu2aBPDdLgKkVhkad4E1hXYw/tNP2DotSN9mZUEI2RRv4B9xvSpZacyb29amZJ2H 7mSohXLlFTyNcYpCIsF8BdtgTHKMwtLBE3C7fPQVEKcTxiigCT3ww6evSCj1DmqLOcyy I1Kz8O8pK3XlBx5oGCdPtYt/Foy/Crxl0Jg2B4DHH7XtoCstqR1RX3+AWPg7p4Wi3BhM snX8kCNw3f4sOGvzt2+A9Xy2thc8BlzzhjQVUF3h3pIfxMYvHTlBg0qiV1BDnNLbbsRf HQBzyqrG8hUqAJMlYuW8GXJP1F3mK7NvpWl/qjSNV7HNYIUBYV9pYGPlgtM8YzQvMAik 0t/g== X-Gm-Message-State: APjAAAUT8dqzixfiXPOkXS4BhFEttaW+tWNGzma7F0q8hhq7i74HEAYB mVh7F0TVLJy6OPxr61uub8zhQTv+ckI= X-Google-Smtp-Source: APXvYqwVnMNpjI8hGfgqQIjU9FuHZhCPmvg+E4X00dfzuxanDaaaWrelx/9FaYCZutNtVR1+sc1Ymg== X-Received: by 2002:a1c:1b81:: with SMTP id b123mr22325156wmb.144.1559815755453; Thu, 06 Jun 2019 03:09:15 -0700 (PDT) Received: from steredhat (host253-229-dynamic.248-95-r.retail.telecomitalia.it. [95.248.229.253]) by smtp.gmail.com with ESMTPSA id r2sm1328122wma.26.2019.06.06.03.09.14 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 06 Jun 2019 03:09:14 -0700 (PDT) Date: Thu, 6 Jun 2019 12:09:12 +0200 From: Stefano Garzarella To: netdev@vger.kernel.org, Stefan Hajnoczi , Dexuan Cui , Jorgen Hansen Cc: "David S. Miller" , Vishnu Dasa , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Sasha Levin Subject: [RFC v2] vsock: proposal to support multiple transports at runtime Message-ID: <20190606100912.f2zuzrkgmdyxckog@steredhat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180716 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi all, this is a v2 of a proposal addressing the comments made by Dexuan, Stefan, and Jorgen. v1: https://www.spinics.net/lists/netdev/msg570274.html We can define two types of transport that we have to handle at the same time (e.g. in a nested VM we would have both types of transport running together): - 'host->guest' transport, it runs in the host and it is used to communicate with the guests of a specific hypervisor (KVM, VMWare or Hyper-V). It also runs in the guest who has nested guests, to communicate with them. [Phase 2] We can support multiple 'host->guest' transport running at the same time, but on x86 only one hypervisor uses VMX at any given time. - 'guest->host' transport, it runs in the guest and it is used to communicate with the host. The main goal is to find a way to decide what transport use in these cases: 1. connect() / sendto() a. use the 'host->guest' transport, if the destination is the guest (dest_cid > VMADDR_CID_HOST). [Phase 2] In order to support multiple 'host->guest' transports running at the same time, we should assign CIDs uniquely across all transports. In this way, a packet generated by the host side will get directed to the appropriate transport based on the CID. b. use the 'guest->host' transport, if the destination is the host or the hypervisor. (dest_cid == VMADDR_CID_HOST || dest_cid == VMADDR_CID_HYPERVISOR) 2. listen() / recvfrom() a. use the 'host->guest' transport, if the socket is bound to VMADDR_CID_HOST, or it is bound to VMADDR_CID_ANY and there is no 'guest->host' transport. We could also define a new VMADDR_CID_LISTEN_FROM_GUEST in order to address this case. [Phase 2] We can support network namespaces to create independent AF_VSOCK addressing domains: - could be used to partition VMs between hypervisors or at a finer granularity; - could be used to isolate host applications from guest applications using the same ports with CID_ANY; b. use the 'guest->host' transport, if the socket is bound to local CID different from the VMADDR_CID_HOST (guest CID get with IOCTL_VM_SOCKETS_GET_LOCAL_CID), or it is bound to VMADDR_CID_ANY (to be backward compatible). Also in this case, we could define a new VMADDR_CID_LISTEN_FROM_HOST. c. shared port space between transports For incoming requests or packets, we should be able to choose which transport use, looking at the 'port' requested. - stream sockets already support shared port space between transports (one port can be assigned to only one transport) [Phase 2] - datagram sockets will support it, but for now VMCI transport is the default transport for any host side datagram socket (KVM and Hyper-V do not yet support datagrams sockets) We will make the loading of af_vsock.ko independent of the transports to allow to: - create a AF_VSOCK socket without any loaded transports; - listen on a socket (e.g. bound to VMADDR_CID_ANY) without any loaded transports; Hopefully, we could move MODULE_ALIAS_NETPROTO(PF_VSOCK) from the vmci_transport.ko to the af_vsock.ko. [Jorgen will check if this will impact the existing VMware products] Notes: - For Hyper-V sockets, the host can only be Windows. No changes should be required on the Windows host to support the changes on this proposal. - Communication between guests are not allowed on any transports, so we can drop packets sent from a guest to another guest (dest_cid > VMADDR_CID_HOST) if the 'host->guest' transport is not available. - [Phase 2] tag used to identify things that can be done at a later stage, but that should be taken into account during this design. - Namespace support will be developed in [Phase 2] or in a separate project. Comments and suggestions are welcome. I'll be on PTO for next two weeks, so sorry in advance if I'll answer later. If we agree on this proposal, when I get back, I'll start working on the code to get a first PATCH RFC. Cheers, Stefano