Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753266AbdHWEVu (ORCPT ); Wed, 23 Aug 2017 00:21:50 -0400 Received: from mail-pu1apc01on0119.outbound.protection.outlook.com ([104.47.126.119]:45293 "EHLO APC01-PU1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751237AbdHWEVo (ORCPT ); Wed, 23 Aug 2017 00:21:44 -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: AdMXLqHUpz8ZGmCVQCq3Yks74VajMAAMewiAAALTwAAAF9gwEAAbKDYAAA5QEwAAruLPgAAGuDGAAB9bwtA= Date: Wed, 23 Aug 2017 04:21:21 +0000 Message-ID: References: <20170817135559.GG5539@stefanha-x1.localdomain> <04460E3B-B213-4090-96CD-00CEEBE6AC32@vmware.com> <20170818153716.GB17572@stefanha-x1.localdomain> <20170822095437.GB16799@stefanha-x1.localdomain> In-Reply-To: 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-22T21:21:18.4448458-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.0.111] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;KL1P15301MB0039;6:rkfvf6DX1BWR0zJwfMyKJuU9FTYdvNsYqT93r9lpFUsplVHiPcvKpeu9jHl7LQ69zkMjNcLpZMEvO3w585Q9O8XErPoEDkz2FxaNsK1erkA+du6/CoDf2/EvH/SB0amB0vgr8+yTeQYcRwT/ekKY7iu5ceU2efMjAkRkrji4x55BGlYzpMaesNLVSRs0gNe4wtYRnX5Zw3HiOx+jJH/s0/PyAbAHE12a7ONNmIAs7sWIfPvB6qvJCEt+o704c0l7fcPKZCA6BqbRihLDM+IAyvPBdTGdysrr42DrfuwBIDCg0m7XlC3DVAOcvEDo7x52cd/kYtXkG/HnbO8vbELGVA==;5:f2MSO2ZY9Yj63gOHKg2gahpdpXs58/aVre/0Pzw29GTS4xUCnzT0S1B1VDucrvbHtaGvqF1SMkH7mQov5t+RU1d/BZ7Md3fpKY5zyk/M6ayX0K5vumFV9Q4BXuyAPVBzKIDDlHCEb8ZyHmmx/+T+lA==;24:iLwOkxAaAxioe/4XF4xqT4pdn2xLIRHLVa/rpbUiK+JtUrFS3bXyq7Rwi/L0bT3YirZuNgxlivvb6sRiwVKX5AybMU6hepZgVTssAnDhfr8=;7:XOJg/5C6lm5SqT5tCYlVotwzkfFkU8hnU2M/wvoPzrmfQoXkqwplLHrCHryMRePPnHhFRM0tB5SFC4ZPILwr8Xc5/vWFpWwTEr5odZ7HubKA4L2RnAe3aAIJMndEAR2Yt9r1k4vi3aueeX1Ft2b1Hv6LJkBsIeIzYVkIxT+DRiTGy79DgGhh3hVjlNRsIJ6D+uvCxngMBYv+TLj0jnL94cE0TH7WSTXR+5Le5qLmy20= x-ms-office365-filtering-correlation-id: 8bebd71a-8760-4ca6-e7b5-08d4e9de68f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:KL1P15301MB0039; x-ms-traffictypediagnostic: KL1P15301MB0039: x-exchange-antispam-report-test: UriScan:(61668805478150)(278428928389397)(21532816269658); 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)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:KL1P15301MB0039;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:KL1P15301MB0039; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(47760400005)(377454003)(189002)(199003)(24454002)(229853002)(8676002)(5660300001)(101416001)(74316002)(86362001)(77096006)(6506006)(6246003)(86612001)(345774005)(53936002)(8936002)(66066001)(2950100002)(6116002)(50986999)(102836003)(189998001)(81156014)(81166006)(76176999)(97736004)(10090500001)(54356999)(3280700002)(3846002)(2906002)(305945005)(7416002)(5005710100001)(7736002)(7696004)(2900100001)(105586002)(53546010)(8990500004)(3660700001)(6436002)(93886005)(55016002)(25786009)(33656002)(4326008)(14454004)(68736007)(9686003)(10290500003)(54906002)(478600001)(106356001);DIR:OUT;SFP:1102;SCL:1;SRVR:KL1P15301MB0039;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: 23 Aug 2017 04:21:21.1962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0039 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 v7N4LuZx013630 Content-Length: 2792 Lines: 64 > From: Jorgen S. Hansen [mailto:jhansen@vmware.com] > > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi > wrote: > > ... > > We *can* by looking at the destination CID. Please take a look at > > drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI > handles > > nested virt. > > > > It boils down to something like this: > > > > static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr, > > int addr_len, int flags) > > { > > ... > > if (remote_addr.svm_cid == VMADDR_CID_HOST) > > transport = host_transport; > > else > > transport = guest_transport; > > > > It's easy for connect(2) but Jorgen mentioned it's harder for listen(2) > > because the socket would need to listen on both transports. We define > > two new constants VMADDR_CID_LISTEN_FROM_GUEST and > > VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can > decide > > which side to listen on. > > If a socket is bound to VMADDR_CID_HOST, we would consider that socket as > bound to the host side transport, so that would be the same as > VMADDR_CID_LISTEN_FROM_GUEST. For the guest, we have > IOCTL_VM_SOCKETS_GET_LOCAL_CID, so that could be used to get and bind > a socket to the guest transport (VMCI will always return the guest CID as the > local one, if the VMCI driver is used in a guest, and it looks like virtio will do > the same). We could treat VMADDR_CID_ANY as always being the guest > transport, since that is the use case where you don’t know upfront what > your CID is, if we don’t want to listen on all transports. So we would use the > host transport, if a socket is bound to VMADDR_CID_HOST, or if there is no > guest transport, and in all other cases use the guest transport. However, > having a couple of symbolic names like you suggest certainly makes it more > obvious, and could be used in combination with this. It would be a plus if > existing applications would function as intended in most cases. > > > Or the listen socket could simply listen to > > both sides. > > The only problem here would be the potential for a guest and a host app to > have a conflict wrt port numbers, even though they would be able to > operate fine, if restricted to their appropriate transport. > > Thanks, > Jorgen Hi Jorgen, Stefan, Thank you for the detailed analysis! You have a much better understanding than me about the complex scenarios. Can you please work out a patch? :-) IMO Linux driver of Hyper-V sockets is the simplest case, as we only have the "to host" option (the host side driver of Hyper-V sockets runs on Windows kernel and I don't think the other hypervisors emulate the full Hyper-V VMBus 4.0, which is required to support Hyper-V sockets). -- Dexuan