From: Zhi Wang <zhiw@nvidia.com>
To: Xu Yilun <yilun.xu@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Alexey Kardashevskiy <aik@amd.com>, <linux-coco@lists.linux.dev>,
Wu Hao <hao.wu@intel.com>, Yilun Xu <yilun.xu@intel.com>,
Lukas Wunner <lukas@wunner.de>, Samuel Ortiz <sameo@rivosinc.com>,
Bjorn Helgaas <bhelgaas@google.com>, <kevin.tian@intel.com>,
<gregkh@linuxfoundation.org>, <linux-pci@vger.kernel.org>,
<zhiwang@kernel.org>
Subject: Re: [RFC PATCH v2 5/6] PCI/TSM: Authenticate devices via platform TSM
Date: Tue, 14 May 2024 20:13:42 +0300 [thread overview]
Message-ID: <20240514195340.0000596e.zhiw@nvidia.com> (raw)
In-Reply-To: <ZjnqZRPaijFxO9rh@yilunxu-OptiPlex-7050>
On Tue, 7 May 2024 16:46:29 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> > > > +
> > > > +/* collect TSM capable devices to rendezvous with the tsm
> > > > driver */ +static DEFINE_XARRAY(pci_tsm_devs);
> > >
> > > imho either this or pci_dev::tsm is enough but not necessarily
> > > both.
> >
> > You mean:
> >
> > s/pci_tsm_devs/tsm_devs/
> >
> > ?
>
> I don't think the concern is just a renaming. My understanding is, we
> already have a struct pci_tsm embedded in struct pci_dev, we could
> loop and find all TSM capable devices by:
>
> for_each_pci_dev(pdev) {
> if (pdev->tsm)
> pci_tsm_add/del(pdev);
> }
>
> A dedicated list for TSM capable devices seems not necessary.
>
> But my concern is about VFs. VFs are as well TSM capable but not
> applicable for tsm_ops->exec(TSM_EXEC_CONNECT), maybe not applicable
> for tsm_ops->add() either. One way to distinguish PF/VFs is we only
> collect PFs in pci_tsm_devs, but all TSM capable devices have
> valid pci_dev::tsm pointer.
>
> TSM capable devices in Guest should not been collected in pci_tsm_devs
> either.
What is the plan for the TSM capable devices in the guest?
My current understanding is there would be host TSM driver and guest
TSM driver, or a vendor TSM driver will have a host mode and a guest
mode due to its nature to understand if it is running in host or a
guest. They will be plugged into the same framework here.
If that is the case, the TSM driver should step in and decide if a
PF/VF can be managed(added) according to its mode. Maybe TSM driver
should also indicate what tdi_verbs it supports. E.g. in the guest
mode, it tells CONNECT is not available but the device can be managed
by the TSM driver.
Thanks,
Zhi.
>
> Thanks,
> Yilun
>
next prev parent reply other threads:[~2024-05-14 17:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 8:51 [RFC PATCH v2 0/6] Towards a shared TSM sysfs-ABI for Confidential Computing Dan Williams
2024-04-12 8:51 ` [RFC PATCH v2 1/6] configfs-tsm: Namespace TSM report symbols Dan Williams
2024-04-12 8:51 ` [RFC PATCH v2 2/6] coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/ Dan Williams
2024-04-12 8:52 ` [RFC PATCH v2 3/6] x86/tdx: Introduce a "tdx" subsystem and "tsm" device Dan Williams
2024-04-12 8:52 ` [RFC PATCH v2 4/6] coco/tsm: Introduce a class device for TEE Security Managers Dan Williams
2024-04-12 8:52 ` [RFC PATCH v2 5/6] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2024-04-13 3:14 ` kernel test robot
2024-04-13 7:34 ` kernel test robot
2024-04-13 11:11 ` kernel test robot
2024-04-19 22:07 ` Bjorn Helgaas
2024-04-27 1:27 ` Dan Williams
2024-04-22 2:21 ` Alexey Kardashevskiy
2024-04-27 2:58 ` Dan Williams
2024-05-06 15:14 ` Xu Yilun
2024-05-07 18:21 ` Dan Williams
2024-05-08 2:21 ` Xu Yilun
2024-05-07 8:46 ` Xu Yilun
2024-05-07 18:28 ` Dan Williams
2024-05-14 17:13 ` Zhi Wang [this message]
2024-04-12 8:52 ` [RFC PATCH v2 6/6] tdx_tsm: TEE Security Manager driver for TDX Dan 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=20240514195340.0000596e.zhiw@nvidia.com \
--to=zhiw@nvidia.com \
--cc=aik@amd.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hao.wu@intel.com \
--cc=kevin.tian@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.com \
--cc=yilun.xu@intel.com \
--cc=yilun.xu@linux.intel.com \
--cc=zhiwang@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.