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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 CB57EC43215 for ; Wed, 13 Nov 2019 16:38:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED5212068F for ; Wed, 13 Nov 2019 16:38:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="B3fvV0aQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728521AbfKMQiv (ORCPT ); Wed, 13 Nov 2019 11:38:51 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:28000 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727835AbfKMQiu (ORCPT ); Wed, 13 Nov 2019 11:38:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573663129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QqzCZrrw+N1LqLUBngxMhEYqWKp5yMdHfOeTcezaP3c=; b=B3fvV0aQqI2IdTj0FBfXfd9gyVROAqBr+BbM2U05MxVkct6bUtImRPAsYesHYBhWyT1YOG DIap0conT6MyRfVR5H993pRcNJJioW5rrwhENnWOh51DEuwC/+oSbmQbmnqbYLuX8F72AY kNq1KmqUiVkHKT/1zGiMfjY+rj/mXBg= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-58-LjnA9GNmP8C3hv9JVzQ6_g-1; Wed, 13 Nov 2019 11:38:48 -0500 Received: by mail-wm1-f71.google.com with SMTP id t203so1416771wmt.7 for ; Wed, 13 Nov 2019 08:38:47 -0800 (PST) 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:references :mime-version:content-disposition:in-reply-to; bh=9rmRmGxbCej/NSmLlrw5qBptbx4sAiez+aV0DPKoxmk=; b=gFxb3Hww+m2+Dz90DO4ro5oIPSkgib96gbBUolF4kiz+dMTKJ7bDLNPfQbACF/Mzbl ovi8IbcXfic0JrJsWyyQBeTzYXWKd+dEFya14JWAdnl+WfggteBi7tuWAimEM/ZA890B 6idVbhnKwlsNFX+24URlcpZ3gT/dCySQ+z0pmY8LOPXZdAjSJFVVXcTyCPoDXUi22bjz ir0qQZ+ikRKCB7OT9vtyYrMtCn0/LCYsClf55MZEfcPjrzMEQMjOStai1VKWHwnD9Sjk 9yAqARUeARxGkUAgzL3AO/35lA3Zmx6nCCpXZxODOXMeYyH5g1Y+h9dbS5Zil2FFd+aR gs7Q== X-Gm-Message-State: APjAAAUnaN+z4oESfrteFSXOYdMm4uIX+l0x66kN5GCXQ2Q6B9VVM0DN XzsaBhTQo7XCx9pomuKo9q+b8wLVFtq989nVA0jvl3zJRJyrscI386no27KoP4neP+EAtbNCiWt zcjamc/+gORpOka9jukOrmHO+ X-Received: by 2002:adf:f0c4:: with SMTP id x4mr2417498wro.217.1573663126801; Wed, 13 Nov 2019 08:38:46 -0800 (PST) X-Google-Smtp-Source: APXvYqxXrDaHddzqNUvTPvMV4jXm5tNoMjrSJ3IvH3rKSatkd4o3Pvp2hT95nFuBwmA+H3+NDewgsg== X-Received: by 2002:adf:f0c4:: with SMTP id x4mr2417472wro.217.1573663126527; Wed, 13 Nov 2019 08:38:46 -0800 (PST) Received: from steredhat (a-nu5-32.tin.it. [212.216.181.31]) by smtp.gmail.com with ESMTPSA id q17sm2813058wmj.12.2019.11.13.08.38.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Nov 2019 08:38:45 -0800 (PST) Date: Wed, 13 Nov 2019 17:38:42 +0100 From: Stefano Garzarella To: Jorgen Hansen Cc: "netdev@vger.kernel.org" , "Michael S. Tsirkin" , "kvm@vger.kernel.org" , Greg Kroah-Hartman , Jason Wang , "David S. Miller" , Dexuan Cui , Haiyang Zhang , Sasha Levin , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Stefan Hajnoczi , "linux-hyperv@vger.kernel.org" , "K. Y. Srinivasan" , Stephen Hemminger , "virtualization@lists.linux-foundation.org" Subject: Re: [PATCH net-next 11/14] vsock: add multi-transports support Message-ID: <20191113163842.6byl2qul4nbjf5no@steredhat> References: <20191023095554.11340-1-sgarzare@redhat.com> <20191023095554.11340-12-sgarzare@redhat.com> <20191111171740.xwo7isdmtt7ywibo@steredhat> <20191112103630.vd3kbk7xnplv6rey@steredhat> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: LjnA9GNmP8C3hv9JVzQ6_g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 13, 2019 at 02:30:24PM +0000, Jorgen Hansen wrote: > > From: Stefano Garzarella [mailto:sgarzare@redhat.com] > > Sent: Tuesday, November 12, 2019 11:37 AM >=20 > > > > > You already mentioned that you are working on a fix for loopback > > > > > here for the guest, but presumably a host could also do loopback. > > > > > > > > IIUC we don't support loopback in the host, because in this case th= e > > > > application will use the CID_HOST as address, but if we are in a ne= sted > > > > VM environment we are in trouble. > > > > > > If both src and dst CID are CID_HOST, we should be fairly sure that t= his > > > Is host loopback, no? If src is anything else, we would do G2H. > > > > >=20 > > The problem is that we don't know the src until we assign a transport > > looking at the dst. (or if the user bound the socket to CID_HOST before > > the connect(), but it is not very common) > >=20 > > So if we are in a L1 and the user uses the local guest CID, it works, b= ut if > > it uses the HOST_CID, the packet will go to the L0. > >=20 > > If we are in L0, it could be simple, because we can simply check if G2H > > is not loaded, so any packet to CID_HOST, is host loopback. > >=20 > > I think that if the user uses the IOCTL_VM_SOCKETS_GET_LOCAL_CID, to se= t > > the dest CID for the loopback, it works in both cases because we return= the > > HOST_CID in L0, and always the guest CID in L1, also if a H2G is loaded= to > > handle the L2. > >=20 > > Maybe we should document this in the man page. >=20 > Yeah, it seems like a good idea to flesh out the routing behavior for nes= ted > VMs in the man page. I'll do it. >=20 > >=20 > > But I have a question: Does vmci support the host loopback? > > I've tried, and it seems not. >=20 > Only for datagrams - not for stream sockets. > =20 Ok, I'll leave the datagram loopback as before. > > Also vhost-vsock doesn't support it, but virtio-vsock does. > >=20 > > > > > > > > Since several people asked about this feature at the KVM Forum, I w= ould > > like > > > > to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and > > implement > > > > loopback in the core. > > > > > > > > What do you think? > > > > > > What kind of use cases are mentioned in the KVM forum for loopback? > > One concern > > > is that we have to maintain yet another interprocess communication > > mechanism, > > > even though other choices exist already (and those are likely to be = more > > efficient > > > given the development time and specific focus that went into those). = To > > me, the > > > local connections are mainly useful as a way to sanity test the proto= col and > > transports. > > > However, if loopback is compelling, it would make sense have it in th= e core, > > since it > > > shouldn't need a specific transport. > >=20 > > The common use cases is for developer point of view, and to test the > > protocol and transports as you said. > >=20 > > People that are introducing VSOCK support in their projects, would like= to > > test them on their own PC without starting a VM. > >=20 > > The idea is to move the code to handle loopback from the virtio-vsock, > > in the core, but in another series :-) >=20 > OK, that makes sense. Thanks, Stefano