From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794587408; b=PKLYHbYbhb3NMvVYx2eGHJuXIdUIkNnC1Sg/PIEaKumRce6TJ+8E4pzHaKQUEVdw1HhV eq+hBdu6gbsxqZ4iNxkWsI49v17YUbMj2ZKeSGWeIHnnVEWS7Pt0Jy1sFfIBGq2SoENTv sNrttVMUaMgjZK4a3LfHPmfeYTrbMISlWQYuKS6834wfbEA5f5v2SnEVFw1MkpBi8WTG3 nM8GIkTbN+K0D/DDJKJOVVACHIUwBSVb392Mn+g5SbTyzHkpqJEYvEq9ohgUN7rOOMa80 doOTZ0gyqMyUjAMITKnWOTLcVo1zOrUmfO7MEHgjKXTVu5jNNU+pqoJ9x0fiPaWCXzQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794587408; h=Received:DKIM-Signature:X-Mailer:From:To:Cc:Subject:In-Reply-To: References:Date:Message-ID:MIME-Version:Content-Type; bh=a05Jwt0oapSs87PUiPXzFARGVbE8ZS0hpaEyecn5Jt4=; b=MfcyjmFZKreqLXI6jWAKaBKv4Q2VaX0mdgqARc3I1Q41yQ44fovEbbJx5x5u5LW0c/qP pyi5tlvdbgld6hfCAOJz/vmB93CzE6k84XetpfCJVEs6KlyReOlboGgiQ1S057t4XGETC Uj4ogIf0TjzRij9MucV+rslFNvxNe/acawVC1ERGBDXJW3WCDPeGLx1300wUUuDlkQagM Tu2yN4KmVcKQTv5Gm1niToc2hjuvs2AogbQcheBWIB8gFThknNBcanU0EHI5IvWodRq3n BFhvDLnlc/gaYxkjZs9fMeJ2xv2LFT5pOmGbkwj0k1/wFzh/S/alyJm+Wxux4xksphg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=oezRNjfB; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 123F0606A88A; Fri, 13 Nov 2026 16:30:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=oezRNjfB Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4E5E1F000C4; Fri, 13 Nov 2026 16:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794587407; bh=a05Jwt0oapSs87PUiPXzFARGVbE8ZS0hpaEyecn5Jt4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=oezRNjfBcdX3wZ6PgVIapUnriVLVMyDxIIdKaQ43cul0OGsvkWYMIveRRbnhvh/Wz aZOlQlcELBiCq1EJ0RcSSr8G9opKYtl9m1f7wVEzpJoekXKoxs6sAT1jSUSZjiyRo6 T1ekeyePC1u1jMKsoLNiH/+bYEDB968llEU49FG4cJI1jlLQOBoFgxbZrk1gc18IUk hKF6yA0afzbdP7H3XYAvB1xJuyuLE7mBRYX146THajTHRFj6njtasNoCJhiS+HDL3f xy029+t01kKqQjB72FHQL4WuYNH378tAHJPJYDAauYKoFzDcelHORQtLHhedmnlBaF GDad5WN8G/1+A== X-Mailer: emacs 31.1 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Jason Gunthorpe Cc: Dave Jiang , "Reshetova, Elena" , Xu Yilun , "linux-coco@lists.linux.dev" , Jiri Pirko , "Tian, Kevin" , Alexey Kardashevskiy , Catalin Marinas , Suzuki K Poulose , Steven Price , Kiryl Shutsemau , "Edgecombe, Rick P" , Dave Hansen , Jonathan Cameron , Bjorn Helgaas , Ashish Kalra , Tom Lendacky , John Allen , Will Deacon , Mark Rutland , "patches@lists.linux.dev" , Alistair Subject: Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance In-Reply-To: <20261113145249.GA3706007@nvidia.com> References: <20261103151643.GI274202@nvidia.com> <20261104134119.GR274202@nvidia.com> <20261106193018.GK770409@nvidia.com> <20261112145254.GL738765@nvidia.com> <20261113145249.GA3706007@nvidia.com> Date: Fri, 13 Nov 2026 21:59:56 +0530 Message-ID: X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain Jason Gunthorpe writes: > On Fri, Nov 13, 2026 at 02:24:59PM +0530, Aneesh Kumar K.V wrote: >> Jason Gunthorpe writes: >> [ ... 150 lines skipped ... ] >> BTW, this proposal does require RMM changes. I have also omitted SPDM >> 1.3 multi-key support from this diagram because it will be easier to >> follow once the SPDM 1.2 flow is clear. > > IMHO, leave everything alone as is today. We can make it work well > enough as is. > Could you describe the flow you have in mind? Would we restrict everything to slot 0, without allowing userspace to select another slot, as this patch series does? > > Make a ECN for a 1.3 opt in broadly like the above that fits better > into how I sketched the kernel uAPI. Do this once we all agree to the > new uAPI. The kernel will always try to use this new mode if RMM > supports it and userspace gets a better 1.3 experiance. I'll reply to this separately to avoid confusing it with the flow we are trying to upstream without firmware changes. -aneesh