Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753980AbdHRDHz (ORCPT ); Thu, 17 Aug 2017 23:07:55 -0400 Received: from mail-hk2apc01on0125.outbound.protection.outlook.com ([104.47.124.125]:9502 "EHLO APC01-HK2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753345AbdHRDHx (ORCPT ); Thu, 17 Aug 2017 23:07:53 -0400 From: Dexuan Cui To: "Jorgen S. Hansen" , Stefan Hajnoczi CC: "davem@davemloft.net" , "netdev@vger.kernel.org" , "gregkh@linuxfoundation.org" , "devel@linuxdriverproject.org" , KY Srinivasan , "Haiyang Zhang" , Stephen Hemminger , George Zhang , Michal Kubecek , Asias He , Vitaly Kuznetsov , "Cathy Avery" , "jasowang@redhat.com" , "Rolf Neugebauer" , Dave Scott , Marcelo Cerri , "apw@canonical.com" , "olaf@aepfle.de" , "joe@perches.com" , "linux-kernel@vger.kernel.org" , Dan Carpenter Subject: RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default Thread-Topic: [PATCH] vsock: only load vmci transport on VMware hypervisor by default Thread-Index: AdMXLqHUpz8ZGmCVQCq3Yks74VajMAAMewiAAALTwAAAF9gwEA== Date: Fri, 18 Aug 2017 03:07:30 +0000 Message-ID: References: <20170817135559.GG5539@stefanha-x1.localdomain> <04460E3B-B213-4090-96CD-00CEEBE6AC32@vmware.com> In-Reply-To: <04460E3B-B213-4090-96CD-00CEEBE6AC32@vmware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=decui@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-08-17T20:07:27.2663826-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: spf=none (sender IP is ) smtp.mailfrom=decui@microsoft.com; x-originating-ip: [167.220.1.201] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;KL1P15301MB0023;6:9c9L0O/S2FC+Udl4A6ZuStJHOuIvixNxG+DZ58QKM9Lj43fhZbJL2UrnBEM+NV3uevhx/7bLs2NQU2YzSpSi+owgs/EElSfla12MAQqTD0WZDFhn8CELuflPiJzXgiPyYWpKynMhircXUfs5YzP5KhHBva87QTLtlWYax2lJvCVOJRFwTkHGbTzOhO0sbVRSq634jPw7Dd2dl+cDXYbwDmIPlqT8vrLp2fZow5ODSZ3ZOTaxX34bfooIZ5Ugu503PMQZiluPOsPAYG1xjK7ied3hIRdnR3gjuR8SfYAOdrkXjEoK9GJvzzdA8d7InmQU6u6BGATYxaxGcxzXL+r9ew==;5:Aioe+Zc1JSJqMx5t3+Kpe/J6Dsl7EUDThPAw/surqFyIPdgByCemq1yFFMEX7Jzi2RkJYXqm2LA7zhh11aM7JXu0gn14xIW83ThphNdRqHVaw8L0SNs85cB9/d7eEG0aNRiXb6WMibOh1mMHpdpCpg==;24:lKJSjOPKyAOMjhq6GMHEK06g44QK+J6Qm0e5hM/GbTCA8IL513HJYbzfMCDYzgJjcNHF3sDflXi9Svi1vLAPtcUGgmd8Z0GgX97Gu3D/TmI=;7:s3Aec+BiY67cPub6ZjbWwG5EolI+/R+iJ2j/T5uQr7pEuN3Fj8pSDHGL2gf68ZbU00vXezfCA0MnbXJCac748s9RJvNZu27VGaURrWJ63xXaklqJcJqOJt/fP0QFXoqP5LNYmN9hB3LAg2l7O2ZG0EHtmdWdrJY5wOR/esSJcwLnlSOtgNFfqP82nUdQ355JukNDF2mNk3LS8jIiJVrog/IxsugAEMX4h3kK3Bw0AW4= x-ms-office365-filtering-correlation-id: afb0c349-3d10-492c-5f18-08d4e5e643b8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:KL1P15301MB0023; x-ms-traffictypediagnostic: KL1P15301MB0023: x-exchange-antispam-report-test: UriScan:(61668805478150)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:KL1P15301MB0023;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:KL1P15301MB0023; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(47760400005)(189002)(199003)(5005710100001)(50986999)(10090500001)(8990500004)(86362001)(54356999)(76176999)(33656002)(9686003)(54906002)(53936002)(101416001)(55016002)(86612001)(6246003)(2900100001)(102836003)(3846002)(6116002)(4326008)(6436002)(25786009)(2950100002)(14454004)(8676002)(81156014)(81166006)(10290500003)(8936002)(305945005)(7736002)(478600001)(3660700001)(3280700002)(74316002)(2906002)(7416002)(106356001)(68736007)(105586002)(189998001)(77096006)(97736004)(229853002)(66066001)(7696004)(5660300001)(6506006);DIR:OUT;SFP:1102;SCL:1;SRVR:KL1P15301MB0023;H:KL1P15301MB0008.APCP153.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 03:07:30.0290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0023 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7I381iE027207 Content-Length: 3101 Lines: 62 > From: Jorgen S. Hansen [mailto:jhansen@vmware.com] > Sent: Thursday, August 17, 2017 08:17 > > > > Putting aside nested virtualization, I want to load the transport (vmci, > > Hyper-V, vsock) for which there is paravirtualized hardware present > > inside the guest. > > Good points. Completely agree that this is the desired behavior for a guest. > > > > It's a little tricker on the host side (doesn't matter for Hyper-V and > > probably also doesn't for VMware) because the host-side driver is a > > software device with no hardware backing it. In KVM we assume the > > vhost_vsock.ko kernel module will be loaded sufficiently early. > > Since the vmci driver is currently tied to PF_VSOCK it hasn’t been a problem, > but on the host side the VMCI driver has no hardware backing it either, so > when we move to a more appropriate solution, this will be an issue for VMCI as > well. I’ll check our shipped products, but they most likely assume that if an > upstreamed vmci module is present, it will be loaded automatically. Hyper-V Sockets is a standard feature of VMBus v4.0, so we can easily know we can and should load iff vmbus_proto_version >= VERSION_WIN10. > > Things get trickier with nested virtualization because the VM might want > > to talk to its host but also to its nested VMs. The simple way of > > fixing this would be to allow two transports loaded simultaneously and > > route traffic destined to CID 2 to the host transport and all other > > traffic to the guest transport. This sounds like a little tricky to me. CID is not really used by us, because we only support guest<->host communication, and don't support guest<->guest communication. The Hyper-V host references every VM by VmID (which is invisible to the VM), and a VM can only talk to the host via this feature. > This is close to the routing the VMCI driver does in a nested environment, but > that is with the assumption that there is only one type of transport. Having two > different transports would require that we delay resolving the transport type > until the socket endpoint has been bound to an address. Things get trickier if > listening sockets use VMADDR_CID_ANY - if only one transport is present, this > would allow the socket to accept connections from both guests and outer host, > but with multiple transports that won’t work, since we can’t associate a socket > with a transport until the socket is bound. > > > > > Perhaps we should discuss these cases a bit more to figure out how to > > avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK). > > Agreed. Can we use the 'protocol' parameter in the socket() function: int socket(int domain, int type, int protocol) IMO currently the 'protocol' is not really used. I think we can modify __vsock_core_init() to allow multiple transport layers to be registered, and we can define different 'protocol' numbers for VMware/KVM/Hyper-V, and ask the application to explicitly specify what should be used. Considering compatibility, we can use the default transport in a given VM depending on the underlying hypervisor. -- Dexuan