From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F2D43845A8 for ; Tue, 3 Mar 2026 09:57:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772531833; cv=none; b=NfaenIMErniO80OxNvqzww0Z1REo1SPtevIjxoyrBytoqXhF8RmSXiqRzQ1TjSKY68LJHDkG2oKkU7iDn44pv2znhzZhXGvTAKfqb0mva5e88WJ45MKJscN1ux3O+7Nzhmy29o3nqokmzNMg038Pnu78d1W628GFJ8gKaZQnZKM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772531833; c=relaxed/simple; bh=aSsbmcc3uv2X4kalVkoQ6KfLu1yix/ZoBPk6o3r4yzE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p+WWG+XgSwAnwi/++KhqOjfgR3pAV+P/V77ubv7/P1Rl9fW7RgehkNSbFcbNOqvlmi/2jf/gH/aZHTygJWw+1EB07cpY75SyuolfH84i1lvJ9KCRgA0+WjjN0+Oy++2lwnQ/9wlMJRyFiG+J0tvrx+ZfbfooGDGY8R6mTTkrQ2g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=c3GhRHEa; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=AbZ9oMV1; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="c3GhRHEa"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="AbZ9oMV1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772531831; 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: in-reply-to:in-reply-to:references:references; bh=2C72I9p1Nz7IP8frqX4kg2UxiKmszT8JtYVPjpeLGo0=; b=c3GhRHEaU434ZA4sccAR9F4WLkZOMf5wrUW2FQE9V2o0a9+kBMznyOiG5GB4jU5ey2xTz7 QRw5+EG9sDgpYVBaRhPjCwLHTjQ6RGYnRAJPgwb669jWDYfpJbHgFKcywPs/QP5TzY38eb rp3o2WfWAfB+mFWD27EZdySQBRDQ7Xk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-UZr07FR_ObyAMrW7ysHx1A-1; Tue, 03 Mar 2026 04:57:10 -0500 X-MC-Unique: UZr07FR_ObyAMrW7ysHx1A-1 X-Mimecast-MFC-AGG-ID: UZr07FR_ObyAMrW7ysHx1A_1772531829 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4837bfcfe0dso68598255e9.1 for ; Tue, 03 Mar 2026 01:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772531829; x=1773136629; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2C72I9p1Nz7IP8frqX4kg2UxiKmszT8JtYVPjpeLGo0=; b=AbZ9oMV1R4IxENJ/igmrvz3H68v6kzkBQ49uCwRBJ6l0orLSDDutNHol9KCF8Yc3z4 vyE/1eaGnZCT92CbIXJgmXo6R45pfH6lCyMyekDVlTbZPjUCZfqRp5+z3T7H+FVsUhc7 oevm0MqR3uYNlHPB8Pt3V10yfVpLPjWdI8oe9EdFRaj8zhrWMP69QPWxKKGh6Tqm1i3Z hA2nXNM/tx+nyGgX+xxyVSWCVMgbVuHSJiaMqbweISsNzsBo9j8klAaUqdRZBw/cQ8Ns bXp84P+47K8TMPTMWJ4XoO56tq15mE8UWQzQ2gsh26wFnrBlmLLcahXfwKj8eQb40zNK 7lgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772531829; x=1773136629; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2C72I9p1Nz7IP8frqX4kg2UxiKmszT8JtYVPjpeLGo0=; b=PNK369VC/p5fQ7J4f34wAvQQ9TjqyLeI2HsH3WiHyRgS7WHQ2vtp11x+M9lIHD2hC5 7cr4XNbi71PBrHdHxYKC2D7wSHdJgHAqy8vB3xqkogdbhm+LNvcG3xtDp0C1Fa3btDJM 8QtMo5Nqv39VLY3VMPd4czz2MFQLVfqpfaQbQBC2qPsSxVgsXyxB1jA9Q2O5icCWWwHB OkNX7jAzHaEFlJZ6JUaQ+a1vCKXFehsyOZKw1NueNoQFN7ZBg7Feyi4tNbPd3nyODWbh S0ogkO4Jfcsfq9hUYQ01u0Tv+BokKDRb9Ot+nIuh6a5pzNSzhtshUMdjZnaeVTQ6+dV4 W0Lg== X-Forwarded-Encrypted: i=1; AJvYcCWCm0Ocpg4AnUDgiDUZWCcnYW9N+6ZUOkswgP9ZRV7J5f/Be7F5IZ3Fd8Wu6/xzvpAaDB5vvoY=@vger.kernel.org X-Gm-Message-State: AOJu0YxdsJ97rhvMgrT/lM4G8NU0c3gfUMMgML1nh9hWquTYvM0Joxjy eXXqAkRjAZ4EH2JFnM64nrHXdhfHkQH+vicK6hvMUdhqr2ZgOI8HVfZUbhG9+3/Jstx2Lv5ihzX hxHB4SGlXtvfWOUnv9q4rNTRwI4t2XWO17GHdjbWWzsDdKmTsJObHUHJJCQ== X-Gm-Gg: ATEYQzy1Ea0e2D24dzr51P+xF5dUDoi5/QWdmYu3KByHzVq4zHADKFuTaqtoYp99ZfD UNLP06B85Y+pG1tmNvsNr+xBsnN48LnC2HPVXwwvvS29Gz03wr36gozdb7ea1U3ndTiMAX7ewGN weBJiqODgouURgapuAtC4Hri3DkeGN564obiRdE98xCdTLYrWhm1pZ9X8ZDpNwRz7M/6WmiYK6Z 1mxTGwvmvt76gzX2BA4FTxabuPwyhI/HxdnsWDzBqU4fwDFRNEcn7DskrhCpiXUBLjO3TZ5BIkZ fh29/VDAfd1NFMR3hxhoU/YLhoLA/uEpM53Rd492+L74La4OAlpCaJv9TazBmLnDxTxP0DdxIO0 OObbISJQc/nlRqD7DhEIgWdtcY+LpgK5GqWjoT9tB29ZIpxtYkt2mO7bCpX+aJemhXJxrTPU= X-Received: by 2002:a05:600c:154b:b0:477:b734:8c53 with SMTP id 5b1f17b1804b1-483c9b9ebd0mr256452485e9.12.1772531828862; Tue, 03 Mar 2026 01:57:08 -0800 (PST) X-Received: by 2002:a05:600c:154b:b0:477:b734:8c53 with SMTP id 5b1f17b1804b1-483c9b9ebd0mr256452075e9.12.1772531828251; Tue, 03 Mar 2026 01:57:08 -0800 (PST) Received: from sgarzare-redhat (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485125bbb48sm21095135e9.0.2026.03.03.01.57.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 01:57:07 -0800 (PST) Date: Tue, 3 Mar 2026 10:57:01 +0100 From: Stefano Garzarella To: "Michael S. Tsirkin" Cc: Alexander Graf , Bryan Tan , Vishnu Dasa , Broadcom internal kernel review list , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, eperezma@redhat.com, Jason Wang , Stefan Hajnoczi , nh-open-source@amazon.com Subject: Re: [PATCH] vsock: Enable H2G override Message-ID: References: <20260302104138.77555-1-graf@amazon.com> <17d63837-6028-475a-90df-6966329a0fc2@amazon.com> <20260302145121-mutt-send-email-mst@kernel.org> <079fcb93-cd01-45db-9ff7-d6cafd8fb7d5@amazon.com> <20260303021723-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260303021723-mutt-send-email-mst@kernel.org> On Tue, Mar 03, 2026 at 02:19:13AM -0500, Michael S. Tsirkin wrote: >On Tue, Mar 03, 2026 at 07:51:32AM +0100, Alexander Graf wrote: >> >> On 02.03.26 20:52, Michael S. Tsirkin wrote: >> > On Mon, Mar 02, 2026 at 04:48:33PM +0100, Alexander Graf wrote: >> > > On 02.03.26 13:06, Stefano Garzarella wrote: >> > > > CCing Bryan, Vishnu, and Broadcom list. >> > > > >> > > > On Mon, Mar 02, 2026 at 12:47:05PM +0100, Stefano Garzarella wrote: >> > > > > Please target net-next tree for this new feature. >> > > > > >> > > > > On Mon, Mar 02, 2026 at 10:41:38AM +0000, Alexander Graf wrote: >> > > > > > Vsock maintains a single CID number space which can be used to >> > > > > > communicate to the host (G2H) or to a child-VM (H2G). The current logic >> > > > > > trivially assumes that G2H is only relevant for CID <= 2 because these >> > > > > > target the hypervisor. However, in environments like Nitro >> > > > > > Enclaves, an >> > > > > > instance that hosts vhost_vsock powered VMs may still want to >> > > > > > communicate >> > > > > > to Enclaves that are reachable at higher CIDs through virtio-vsock-pci. >> > > > > > >> > > > > > That means that for CID > 2, we really want an overlay. By default, all >> > > > > > CIDs are owned by the hypervisor. But if vhost registers a CID, >> > > > > > it takes >> > > > > > precedence. Implement that logic. Vhost already knows which CIDs it >> > > > > > supports anyway. >> > > > > > >> > > > > > With this logic, I can run a Nitro Enclave as well as a nested VM with >> > > > > > vhost-vsock support in parallel, with the parent instance able to >> > > > > > communicate to both simultaneously. >> > > > > I honestly don't understand why VMADDR_FLAG_TO_HOST (added >> > > > > specifically for Nitro IIRC) isn't enough for this scenario and we >> > > > > have to add this change. Can you elaborate a bit more about the >> > > > > relationship between this change and VMADDR_FLAG_TO_HOST we added? >> > > >> > > The main problem I have with VMADDR_FLAG_TO_HOST for connect() is that it >> > > punts the complexity to the user. Instead of a single CID address space, you >> > > now effectively create 2 spaces: One for TO_HOST (needs a flag) and one for >> > > TO_GUEST (no flag). But every user space tool needs to learn about this >> > > flag. That may work for super special-case applications. But propagating >> > > that all the way into socat, iperf, etc etc? It's just creating friction. >> > > >> > > IMHO the most natural experience is to have a single CID space, potentially >> > > manually segmented by launching VMs of one kind within a certain range. >> > > >> > > At the end of the day, the host vs guest problem is super similar to a >> > > routing table. >> > If this is what's desired, some bits could be stolen from the CID >> > to specify the destination type. Would that address the issue? >> > Just a thought. Nope :-( VMMs some times use random u32 to set CID (avoiding reserved ones like 0, 1, 2, 3, U32_MAX). We also documented them in virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4780004 >> >> >> If we had thought of this from the beginning, yes. But now that everyone >> thinks CID (guest) == CID (host), I believe this is no longer feasible. We added a new flag (VMADDR_FLAG_TO_HOST) in struct sockaddr_vm exactly for that use case around 6 years ago [1], but not much work was done to propagate that change to userspace tools. IMO that should be improved, and if for Nitro this is useful, you should try to help on that effort. Stefano [1] https://lore.kernel.org/netdev/20201214161122.37717-1-andraprs@amazon.com/ >> >> >> Alex > > >I don't really insist, but just to point out that if we wanted to, we >could map multiple CIDs to host. Anyway.