Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@linux.intel.com>
To: dan.j.williams@intel.com
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>,
	linux-coco@lists.linux.dev, linux-pci@vger.kernel.org,
	xin@zytor.com, chao.gao@intel.com
Subject: Re: [RFC PATCH 20/27] coco/tdx-host: Add connect()/disconnect() handlers prototype
Date: Thu, 13 Nov 2025 10:51:17 +0800	[thread overview]
Message-ID: <aRVHpdQ637ltYJku@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <69128889c6c2d_1d911009f@dwillia2-mobl4.notmuch>

On Mon, Nov 10, 2025 at 04:51:21PM -0800, dan.j.williams@intel.com wrote:
> Xu Yilun wrote:
> > On Mon, Nov 03, 2025 at 03:34:15PM -0800, dan.j.williams@intel.com wrote:
> > > Jonathan Cameron wrote:
> > > > On Fri, 19 Sep 2025 07:22:29 -0700
> > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > 
> > > > > From: Xu Yilun <yilun.xu@linux.intel.com>
> > > > > 
> > > > > Add basic skeleton for connect()/disconnect() handlers. The major steps
> > > > > are SPDM setup first and then IDE selective stream setup.
> > > > > 
> > > > > No detailed TDX Connect implementation.
> > > > > 
> > > > > Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> > > > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > > > Feels like use of __free() in here is inappropriate to me.
> > > > 
> > > > > ---
> > > > >  drivers/virt/coco/tdx-host/tdx-host.c | 49 ++++++++++++++++++++++++++-
> > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/virt/coco/tdx-host/tdx-host.c b/drivers/virt/coco/tdx-host/tdx-host.c
> > > > > index f5a869443b15..0d052a1acf62 100644
> > > > > --- a/drivers/virt/coco/tdx-host/tdx-host.c
> > > > > +++ b/drivers/virt/coco/tdx-host/tdx-host.c
> > > > > @@ -104,13 +104,60 @@ static int __maybe_unused tdx_spdm_msg_exchange(struct tdx_link *tlink,
> > > > >  	return ret;
> > > > 
> > > > > +
> > > > > +static void __tdx_link_disconnect(struct tdx_link *tlink)
> > > > > +{
> > > > > +	tdx_ide_stream_teardown(tlink);
> > > > > +	tdx_spdm_session_teardown(tlink);
> > > > > +}
> > > > > +
> > > > > +DEFINE_FREE(__tdx_link_disconnect, struct tdx_link *, if (_T) __tdx_link_disconnect(_T))
> > > > > +
> > > > >  static int tdx_link_connect(struct pci_dev *pdev)
> > > > >  {
> > > > > -	return -ENXIO;
> > > > > +	struct tdx_link *tlink = to_tdx_link(pdev->tsm);
> > > > > +	int ret;
> > > > > +
> > > > > +	struct tdx_link *__tlink __free(__tdx_link_disconnect) = tlink;
> > > > I'm not a fan on an ownership pass like this just for purposes of cleaning up.
> > > 
> > > Yeah this needs a rethink. The session and the stream are independent
> > > resources. It can be a composite object that encapsulates both
> > > resources, but not tlink directly.
> > > 
> > > ...chalk this up to RFC expediency.
> > > 
> > > > I'd be a bit happier if you could make it
> > > > 	struct tdx_link *tlink __free(__tdx_link_disconnect) = to_tdx_link(pdev->dsm);
> > > > 
> > > > but I still don't really like it.  I think I'd just not use __free and stick
> > > > to traditional cleanup in via a goto. 
> > > 
> > > I would not go that far, but certainly I can see that being preferable
> > > than reusing the existing base 'struct tdx_link *' as the cleanup
> > > variable.
> > 
> > The latest implementation internally is as follows. tlink_spdm &
> > tlink_ide represent independent resources though they point to the same
> > instance. I'm already comfortable about this code:
> > 
> > static int tdx_link_connect(struct pci_dev *pdev)
> > {
> > 	struct tdx_link *tlink = to_tdx_link(pdev->tsm);
> > 
> > 	struct tdx_link *tlink_spdm __free(tdx_spdm_session_teardown) =
> > 		tdx_spdm_session_setup(tlink);
> 
> The question I have is why does tdx_spdm_session_setup() return a
> 'struct tdx_link' instance and not a new 'struct tdx_spdm' object to
> represent the new resources that were acquired? 'struct tdx_link' is
> base infrastructure created by ->probe(). Perhaps 'struct tdx_spdm'
> could be:
> 
> struct tdx_spdm {
>        u64 spdm_id;
>        struct page *spdm_conf;
>        struct tdx_page_array *spdm_mt;
> }
> 
> ...and then tdx_link becomes:
> 
> struct tdx_link {
> 	...
> 	struct tdx_spdm spdm;
> };
> 
> ...and you can do:
> 
>        struct tdx_spdm *spdm __free(tdx_spdm_session_teardown) =
>                tdx_spdm_session_setup(tlink);
> 
> tlink->spdm = *no_free_ptr(spdm);
> 
> ...to assign it back to the preallocated space in @tlink, or make
> it dynamically allocated.
> 
> struct tdx_link {
> 	...
> 	struct tdx_spdm *spdm;
> };
> 
> tlink->spdm = no_free_ptr(spdm);

It works for sure. I have also thought about this solution, but dropped.
I don't wanna see the usage of auto-cleanup impose too much influences
to the code/structure design, even if it shows better modularity.

It is normal in kernel that a base structure contains several
sub-features and we just group them with blank lines. Some fields may be
used accoss 1-2 features and doesn't have a clear owner. If we ask for
strict structure/flow design for auto-cleanup, people may reluctant to
switch to auto-cleanup, thought is it over-engineering?

IOW, I like this current piece of code cause it is in perfect balance.
I don't have to change the mindset much for code design. I get the benifit
of auto-cleanup, and the local cleanup handlers (tlink_spdm, tlink_ide)
are cheap but clearly tell me what will happen if any step fails.

> 
> > 	if (IS_ERR(tlink_spdm)) {
> > 		pci_err(pdev, "fail to setup spdm session\n");
> > 		return PTR_ERR(tlink_spdm);
> > 	}
> > 
> > 	struct tdx_link *tlink_ide __free(tdx_ide_stream_teardown) =
> > 		tdx_ide_stream_setup(tlink);
> > 	if (IS_ERR(tlink_ide)) {
> > 		pci_err(pdev, "fail to setup ide stream\n");
> > 		return PTR_ERR(tlink_ide);
> > 	}
> 
> No strict need for scope-based cleanup if this is the last resource
> acquisition,

So if we don't do auto-cleanup for the last one, do we still need a
structure for that? If not,

 struct tdx_link {
	struct tdx_spdm *spdm;
	
	int ide_stream_field1;
	int ide_stream_field2;
	...
 }

seems so wierd.

> but maybe there are other PCI/TSM core things to do that
> are not shown.

There is no following items for now but I think cleanup for the last one
is good. Otherwise we may face with the same problem as goto, that we
see unrelated changes (add cleanup for previous one) when we add a new
step.

Thanks,
Yilun


  reply	other threads:[~2025-11-13  3:05 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 14:22 [RFC PATCH 00/27] PCI/TSM: TDX Connect: SPDM Session and IDE Establishment Dan Williams
2025-09-19 14:22 ` [RFC PATCH 01/27] coco/tdx-host: Introduce a "tdx_host" device Dan Williams
2025-10-30 10:16   ` Jonathan Cameron
2025-11-03 23:01     ` dan.j.williams
2025-09-19 14:22 ` [RFC PATCH 02/27] x86/virt/tdx: Move bit definitions of TDX_FEATURES0 to public header Dan Williams
2025-09-19 14:22 ` [RFC PATCH 03/27] coco/tdx-host: Support Link TSM for TDX host Dan Williams
2025-10-30 10:31   ` Jonathan Cameron
2025-11-03 23:04     ` dan.j.williams
2025-09-19 14:22 ` [RFC PATCH 04/27] x86/virt/tdx: Move tdx_errno.h from KVM to public place Dan Williams
2025-09-22 11:47   ` Huang, Kai
2025-09-19 14:22 ` [RFC PATCH 05/27] x86/virt/tdx: Add tdx_page_array helpers for new TDX Module objects Dan Williams
2025-10-30 10:49   ` Jonathan Cameron
2025-11-03 23:17     ` dan.j.williams
2025-09-19 14:22 ` [RFC PATCH 06/27] x86/virt/tdx: Add SEAMCALL wrappers for TDH.EXT.MEM.ADD and TDH.EXT.INIT Dan Williams
2025-09-19 14:22 ` [RFC PATCH 07/27] TODO: x86/virt/tdx: Read TDX global metadata for TDX Module Extensions Dan Williams
2025-09-19 14:22 ` [RFC PATCH 08/27] x86/virt/tdx: Add tdx_enable_ext() to enable of " Dan Williams
2025-10-30 10:55   ` Jonathan Cameron
2025-11-05  9:14     ` Xu Yilun
2025-09-19 14:22 ` [RFC PATCH 09/27] ACPICA: Add KEYP table definitions Dan Williams
2025-10-06 14:41   ` Samuel Ortiz
2025-10-10  7:35     ` Xu Yilun
2025-09-19 14:22 ` [RFC PATCH 10/27] acpi: Add KEYP support to fw_table parsing Dan Williams
2025-09-19 14:22 ` [RFC PATCH 11/27] acpi: Add KEYP Key Configuration Unit parsing Dan Williams
2025-10-30 11:02   ` Jonathan Cameron
2025-11-05 10:18     ` Xu Yilun
2025-09-19 14:22 ` [RFC PATCH 12/27] iommu/vt-d: Cache max domain ID to avoid redundant calculation Dan Williams
2025-09-19 14:22 ` [RFC PATCH 13/27] iommu/vt-d: Reserve the MSB domain ID bit for the TDX module Dan Williams
2025-09-19 14:22 ` [RFC PATCH 14/27] TODO: x86/virt/tdx: Read TDX Connect global metadata for TDX Connect Dan Williams
2025-09-19 14:22 ` [RFC PATCH 15/27] x86/virt/tdx: Extend tdx_page_array to support IOMMU_MT Dan Williams
2025-10-30 11:07   ` Jonathan Cameron
2025-09-19 14:22 ` [RFC PATCH 16/27] x86/virt/tdx: Add SEAMCALL wrappers for trusted IOMMU setup and clear Dan Williams
2025-09-19 14:22 ` [RFC PATCH 17/27] iommu/vt-d: Export a helper to do function for each dmar_drhd_unit Dan Williams
2025-09-19 14:22 ` [RFC PATCH 18/27] coco/tdx-host: Setup all trusted IOMMUs on TDX Connect init Dan Williams
2025-10-30 11:09   ` Jonathan Cameron
2025-09-19 14:22 ` [RFC PATCH 19/27] coco/tdx-host: Add a helper to exchange SPDM messages through DOE Dan Williams
2025-10-30 11:15   ` Jonathan Cameron
2025-09-19 14:22 ` [RFC PATCH 20/27] coco/tdx-host: Add connect()/disconnect() handlers prototype Dan Williams
2025-10-30 11:20   ` Jonathan Cameron
2025-11-03 23:34     ` dan.j.williams
2025-11-06  5:18       ` Xu Yilun
2025-11-10 11:45         ` Jonathan Cameron
2025-11-11  0:51         ` dan.j.williams
2025-11-13  2:51           ` Xu Yilun [this message]
2025-11-14 20:19             ` dan.j.williams
2025-11-17  4:56               ` Xu Yilun
2025-09-19 14:22 ` [RFC PATCH 21/27] x86/virt/tdx: Add SEAMCALL wrappers for SPDM management Dan Williams
2025-10-30 11:24   ` Jonathan Cameron
2025-11-03 23:38     ` dan.j.williams
2025-09-19 14:22 ` [RFC PATCH 22/27] coco/tdx-host: Implement SPDM session setup Dan Williams
2025-10-30 11:36   ` Jonathan Cameron
2025-11-06  7:35     ` Xu Yilun
2025-09-19 14:22 ` [RFC PATCH 23/27] PCI: iov: Export pci_iov_virtfn_bus() Dan Williams
2025-09-19 14:22 ` [RFC PATCH 24/27] PCI/IDE: Add helpers for RID/Addr Association Registers setup Dan Williams
2025-09-19 14:22 ` [RFC PATCH 25/27] PCI/IDE: Export pci_ide_domain() Dan Williams
2025-09-19 14:22 ` [RFC PATCH 26/27] x86/virt/tdx: Add SEAMCALL wrappers for IDE stream management Dan Williams
2025-10-30 11:37   ` Jonathan Cameron
2025-09-19 14:22 ` [RFC PATCH 27/27] coco/tdx-host: Implement IDE stream setup/teardown Dan Williams
2025-10-30 11:43   ` Jonathan Cameron
2025-11-04  0:13     ` dan.j.williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aRVHpdQ637ltYJku@yilunxu-OptiPlex-7050 \
    --to=yilun.xu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-pci@vger.kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox