From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 5DBEF38AC8B; Wed, 27 May 2026 22:49:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779922146; cv=none; b=T5l1hvyqhoglMkR5LFVeI9Ew/IGaODzq6K42ny7cpyU36NffG9rH7LOKf9ts2KrFp5Fh5v7GpCchJxDNVY/nY05ODPVczN9WiexCN0pb5AaSaYERPjt/uRf4hzHID8ljFFqbN4GeznwTKZEqq3wu7tT0LpnmEgfift1soXrADto= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779922146; c=relaxed/simple; bh=XgCimAoT7hxbVKi27EM2uVlOhhGmrOb94/8bSorKk6o=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=lCveeWXPtIGs0CJQ8vPtldn0zHWmRRvxhDfSnoCT6hcPouLLzityAVbPe5+L54Gj0FH5fM7uVQVQRjdu2jBeRNrtSUSr4Bye9jagg8L+sodOrj4uxOwqeVTzBMUHlnWZaw6D4LsMuNm+ys2EpyeKZawNjbi33zH0o68iKxKniSA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cQM/7+mO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cQM/7+mO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 177CB1F000E9; Wed, 27 May 2026 22:49:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779922144; bh=kbwvCEgGUo53H1eMdHinsXodo5C04fK1nklZJsj/WrU=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=cQM/7+mO8VkPa5CyqU7+3Is7n83xQ1wTp7m1cbSHeli0D7CDAFCdvKaO4FqJznfCK v6nHTXxEiQUqSTTZIjHACctKfW7Mkt1PMwL1e+MiNgYnks9StIQxsbBPUyOiuqvIfP qjmmq/H7G8HSIg7GlM0OEQ4q72CduXppq7DOmfi35RZFpEuNs1mGBUMWfRv8zj5cFJ BkFqOrPK+InbY8KSFo4yaQtrWmGVN6vG1u0wIFgveU7rgS/COiX7kfuVO+jD4/Bzdm BOGodh+hA0xMBy1rRT71ZJc64te9C2/sLdJXaHbvzWqeUdyk2JCdSuSTkK96IjD9Sg rCjRyLQ5kpsBA== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.phl.internal (Postfix) with ESMTP id 5353AF4006B; Wed, 27 May 2026 18:49:03 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 27 May 2026 18:49:03 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEKosdjcGQ0fUzOjNmQ2DaCEkmXgDIgGtQ7CeozMDS1NKqLYgRoYzp4SrcRkoePGh I3/0gP8U7PceQZ5VeBofkCCiqKdtXu/IVi1l7qzDRfWoqulRf4ZxWwe+5xsnELv45z+f/G MaW/6HK6PZ9Po7ctNfm2S2K8YTLug1Wy65sJ4o5Ro+jeumn5uaFuZ85G3XiIiuz96lPvyJ 5fVFLuiNLia/ofcgArMi7jyfqb+AyocmjpvFTrvevVedErrFHWQvg4mrVFRK+7hxI8TP9M mH1GI7EFK4AsYlNCrehRXq0VRcua8GPJN1WdVOwJgcw1qyxxLSJNDVONOXjRw9Ti6ErZO8 IrHD8LSA2YBfCifjnv7QIoH3nmTTq5UhqXrsa2xxfEYB5iGFJ+/B967wkejXSzOP9s9tkv UziHZTPytzoznWs846mNcKteLWm5xtwTynhnjOrk5gw8NB5l1etb2x+/nrPDugBmnBBK/v 1D0lDSGZ10+FSjJsdy6DjVLLoKrjKk78XVjOo/5ByP2KjEIVJvPtPm0VVSuBJj4eR3Sjyv V6VDIJElnseu4xowOBfRXXRYf2l5RdjZ7CSob4xY0gEA9sCwels/KxGLYUc6MfH6UAP10J Ki7RBESOfd6GCyV5R5advgpW4KSHN05EtIQ+9TPuuk3AJBaPYbxgY5UdHtyA X-ME-Proxy: Feedback-ID: i67ae4b3e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 May 2026 18:49:02 -0400 (EDT) Date: Wed, 27 May 2026 15:49:01 -0700 From: "Dan Williams (nvidia)" To: "Aneesh Kumar K.V" , "Dan Williams (nvidia)" , Alexey Kardashevskiy , linux-coco@lists.linux.dev, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Bjorn Helgaas , Dan Williams , Jason Gunthorpe , Joerg Roedel , Jonathan Cameron , Kevin Tian , Nicolin Chen , Samuel Ortiz , Steven Price , Suzuki K Poulose , Will Deacon , Xu Yilun , Shameer Kolothum , Paolo Bonzini , Tony Krowiak , Halil Pasic , Jason Herne , Harald Freudenberger , Holger Dengler , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Alex Williamson , Matthew Rosato , Farhan Ali , Eric Farman , linux-s390@vger.kernel.org Message-ID: <6a1774dd80f74_19737610095@djbw-dev.notmuch> In-Reply-To: References: <20260525154816.1029642-1-aneesh.kumar@kernel.org> <20260525154816.1029642-6-aneesh.kumar@kernel.org> <6a168c8ea7d10_2129b2100e@djbw-dev.notmuch> Subject: Re: [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aneesh Kumar K.V wrote: > >> I am leaning towards the latter at this point. > > > > But we already have struct pci_tsm_ops::guest_req, which is specific = to > > the underlying CC architecture. From the above, pci_tsm_req_scope als= o > > appears to carry the same information. Is that useful? > > > = > I think there is value in having the VMM express the guest=E2=80=99s > confidential computing architecture, so that the TSM backend can > validate whether it should handle that guest request ?. Yes, that is the idea. > So it would not be the IOMMU validating the scope value, but rather > pci_tsm_ops::guest_req. > = > static ssize_t cca_tsm_guest_req(struct pci_tdi *tdi, enum pci_tsm_req_= scope scope, > sockptr_t req, size_t req_len, sockptr_t resp, > size_t resp_len, u64 *tsm_code) > { > struct pci_dev *pdev =3D tdi->pdev; > = > /* reject the guest request if VMM was using the link tsm wrongly. The= guest > * was using a wrong CC archiecture with this link tsm > */ > if (scope !=3D TSM_REQ_TYPE_CCA) > return -EINVAL; Right, iommufd is tunneling TSM requests. The tunnel should have an envelope of TSM_REQ_TYPE_* and an @op field. The TSM driver gets those from iommufd, validates the envelope and then processes @req. This self-consistency and explicitness also buys some future-proofing. It allows for alternate command sets within an arch, cross TSM implementation shared commands, IOMMUFD-to-TSM requests outside of guest requests. > Jason Gunthorpe writes: > = > > On Tue, May 26, 2026 at 11:17:50PM -0700, Dan Williams (nvidia) wrote= : > > > >> In that case pci_tsm_req_scope becomes tsm_req_type and is just: > >> = > >> TSM_REQ_TYPE_CCA > >> TSM_REQ_TYPE_SEV > >> TSM_REQ_TYPE_TDX > >> = > >> I am leaning towards the latter at this point. > > > > Yeah, this sounds good. I would also include an common op field that > > can be decoded by the TSM driver based on the TYPE above, and the > > usual in/out message buffers. > = > We already have iommufd_vdevice_tsm_op_ioctl() to handle common > operations. Per above, I believe this is about an @op value in a common location that iommufd can forward to the backend for validation of guest requests. > Right now, it handles IOMMU_VDEVICE_TSM_BIND and > IOMMU_VDEVICE_TSM_UNBIND. I guess we should move TSM_REQ_SET_TDI_STATE > operations to that as well? I think we can wait to move it to its own IOMMU operation unless/until there is a need to set RUN outside of an explicit guest request, right?=