From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: <linux-coco@lists.linux.dev>, <linux-pci@vger.kernel.org>,
<gregkh@linuxfoundation.org>, <lukas@wunner.de>,
<aneesh.kumar@kernel.org>, <suzuki.poulose@arm.com>,
<sameo@rivosinc.com>, <aik@amd.com>, <jgg@nvidia.com>,
<zhiw@nvidia.com>, Bjorn Helgaas <bhelgaas@google.com>,
Xu Yilun <yilun.xu@linux.intel.com>
Subject: Re: [PATCH v3 03/13] PCI/TSM: Authenticate devices via platform TSM
Date: Tue, 17 Jun 2025 13:51:45 +0100 [thread overview]
Message-ID: <20250617135145.0000376b@huawei.com> (raw)
In-Reply-To: <20250516054732.2055093-4-dan.j.williams@intel.com>
On Thu, 15 May 2025 22:47:22 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> The PCIe 6.1 specification, section 11, introduces the Trusted Execution
> Environment (TEE) Device Interface Security Protocol (TDISP). This
> protocol definition builds upon Component Measurement and Authentication
> (CMA), and link Integrity and Data Encryption (IDE). It adds support for
> assigning devices (PCI physical or virtual function) to a confidential
> VM such that the assigned device is enabled to access guest private
> memory protected by technologies like Intel TDX, AMD SEV-SNP, RISCV
> COVE, or ARM CCA.
>
> The "TSM" (TEE Security Manager) is a concept in the TDISP specification
> of an agent that mediates between a "DSM" (Device Security Manager) and
> system software in both a VMM and a confidential VM. A VMM uses TSM ABIs
> to setup link security and assign devices. A confidential VM uses TSM
> ABIs to transition an assigned device into the TDISP "RUN" state and
> validate its configuration. From a Linux perspective the TSM abstracts
> many of the details of TDISP, IDE, and CMA. Some of those details leak
> through at times, but for the most part TDISP is an internal
> implementation detail of the TSM.
>
> CONFIG_PCI_TSM adds an "authenticated" attribute and "tsm/" subdirectory
> to pci-sysfs. Consider that the TSM driver may itself be a PCI driver.
> Userspace can watch for the arrival of the "TSM" core device,
> /sys/class/tsm/tsm0/uevent, to know when the PCI core has initialized
> TSM services.
>
> The common verbs that the low-level TSM drivers implement are defined by
> 'struct pci_tsm_ops'. For now only 'connect' and 'disconnect' are
> defined for secure session and IDE establishment. The 'probe' and
> 'remove' operations setup per-device context objects starting with
> 'struct pci_tsm_pf0', the device Physical Function 0 that mediates
> communication to the device's Security Manager (DSM).
>
> The locking allows for multiple devices to be executing commands
> simultaneously, one outstanding command per-device and an rwsem
> synchronizes the implementation relative to TSM
> registration/unregistration events.
>
> Thanks to Wu Hao for his work on an early draft of this support.
>
> Cc: Lukas Wunner <lukas@wunner.de>
> Cc: Samuel Ortiz <sameo@rivosinc.com>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Co-developed-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Trivial stuff on this one. See inline.
Jonathan
> ---
> Documentation/ABI/testing/sysfs-bus-pci | 45 +++
> MAINTAINERS | 2 +
> drivers/pci/Kconfig | 14 +
> drivers/pci/Makefile | 1 +
> drivers/pci/pci-sysfs.c | 4 +
> drivers/pci/pci.h | 10 +
> drivers/pci/probe.c | 1 +
> drivers/pci/remove.c | 3 +
> drivers/pci/tsm.c | 437 ++++++++++++++++++++++++
> drivers/virt/coco/host/tsm-core.c | 19 +-
> include/linux/pci-tsm.h | 138 ++++++++
> include/linux/pci.h | 3 +
> include/linux/tsm.h | 4 +-
> include/uapi/linux/pci_regs.h | 1 +
> 14 files changed, 679 insertions(+), 3 deletions(-)
> create mode 100644 drivers/pci/tsm.c
> create mode 100644 include/linux/pci-tsm.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
> index 69f952fffec7..1d38e0d3a6be 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci
> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> @@ -612,3 +612,48 @@ Description:
>
> # ls doe_features
> 0001:01 0001:02 doe_discovery
> +
> +What: /sys/bus/pci/devices/.../tsm/
> +Date: July 2024
Guess the date for merge?
> +Contact: linux-coco@lists.linux.dev
> +Description:
> diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
> new file mode 100644
> index 000000000000..d00a8e471340
> --- /dev/null
> +++ b/drivers/pci/tsm.c
> @@ -0,0 +1,437 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TEE Security Manager for the TEE Device Interface Security Protocol
> + * (TDISP, PCIe r6.1 sec 11)
> + *
> + * Copyright(c) 2024 Intel Corporation. All rights reserved.
> + */
> +
> +#define dev_fmt(fmt) "TSM: " fmt
> +
> +#include <linux/bitfield.h>
> +#include <linux/xarray.h>
Not seeing an xa stuff yet.
Check the others are all needed or push them forwards to appropriate patch.
> +#include <linux/sysfs.h>
> +
> +#include <linux/pci.h>
> +#include <linux/pci-doe.h>
> +#include <linux/pci-tsm.h>
> +#include "pci.h"
> +static bool pci_tsm_pf0_group_visible(struct kobject *kobj)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (pdev->tsm && is_pci_tsm_pf0(pdev))
> + return true;
> + return false;
Unless this is going to get more complex later
return pdev->tsm && is_pci_tsm_pf0(pdev);
> +}
> +DEFINE_SIMPLE_SYSFS_GROUP_VISIBLE(pci_tsm_pf0);
> +
> +const struct attribute_group pci_tsm_auth_attr_group = {
> + .attrs = pci_tsm_auth_attrs,
> + .is_visible = SYSFS_GROUP_VISIBLE(pci_tsm_pf0),
> +};
> +static void pci_tsm_pf0_init(struct pci_dev *pdev)
> +{
> + bool tee_cap;
> +
> + tee_cap = pdev->devcap & PCI_EXP_DEVCAP_TEE;
Might as well put that on first line.
> +
> + if (!(pdev->ide_cap || tee_cap))
> + return;
> diff --git a/drivers/virt/coco/host/tsm-core.c b/drivers/virt/coco/host/tsm-core.c
> index 4f64af1a8967..51146f226a64 100644
> --- a/drivers/virt/coco/host/tsm-core.c
> +++ b/drivers/virt/coco/host/tsm-core.c
> @@ -8,11 +8,13 @@
> #include <linux/device.h>
> #include <linux/module.h>
> #include <linux/cleanup.h>
> +#include <linux/pci-tsm.h>
>
> static DECLARE_RWSEM(tsm_core_rwsem);
> static struct class *tsm_class;
> static struct tsm_core_dev {
> struct device dev;
> + const struct pci_tsm_ops *pci_ops;
> } *tsm_core;
>
> static struct tsm_core_dev *
> @@ -39,7 +41,8 @@ static void put_tsm_core(struct tsm_core_dev *core)
> DEFINE_FREE(put_tsm_core, struct tsm_core_dev *,
> if (!IS_ERR_OR_NULL(_T)) put_tsm_core(_T))
> struct tsm_core_dev *tsm_register(struct device *parent,
> - const struct attribute_group **groups)
> + const struct attribute_group **groups,
> + const struct pci_tsm_ops *pci_ops)
> {
> struct device *dev;
> int rc;
> @@ -61,10 +64,20 @@ struct tsm_core_dev *tsm_register(struct device *parent,
> if (rc)
> return ERR_PTR(rc);
>
> + rc = pci_tsm_core_register(pci_ops, NULL);
> + if (rc) {
> + dev_err(parent, "PCI initialization failure: %pe\n",
> + ERR_PTR(rc));
> + return ERR_PTR(rc);
> + }
> +
> rc = device_add(dev);
> - if (rc)
> + if (rc) {
> + pci_tsm_core_unregister(pci_ops);
> return ERR_PTR(rc);
> + }
>
> + core->pci_ops = pci_ops;
> tsm_core = no_free_ptr(core);
>
> return tsm_core;
> @@ -79,7 +92,9 @@ void tsm_unregister(struct tsm_core_dev *core)
> return;
> }
>
> + pci_tsm_core_unregister(core->pci_ops);
> device_unregister(&core->dev);
Using device_initialize() and device_add() in probe but device_unregister()
in remove results in trivial ordering mess like this. I'd split the
remove() path so we can take down in the reverse of setup with pci_tsm_core_unregister()
between device_del() and put_device()
This ordering thing is common enough though that maybe we can just
not worry about it.
> +
Push whitespace change back to earlier patch.
> tsm_core = NULL;
> }
> EXPORT_SYMBOL_GPL(tsm_unregister);
> diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
> new file mode 100644
> index 000000000000..00fdae087069
> --- /dev/null
> +++ b/include/linux/pci-tsm.h
> @@ -0,0 +1,138 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __PCI_TSM_H
> +#define __PCI_TSM_H
> +#include <linux/mutex.h>
> +#include <linux/pci.h>
> +
> +struct pci_dev;
Given you have linux/pci.h no need for the forwards def.
> +
> +enum pci_tsm_state {
> + PCI_TSM_ERR = -1,
> + PCI_TSM_INIT,
> + PCI_TSM_CONNECT,
> +};
> +
> +/**
> + * enum pci_tsm_type - 'struct pci_tsm' object types
Kernel-doc should warn on incomplete docs. I'd add trivial comment for
INVALID to avoid that.
> + * @PCI_TSM_PF0: function0 that hosts a DOE mailbox that comprehends an
> + * Interface ID per potential TDI
> + * @PCI_TSM_VIRTFN: physfn-0 of this device is "tsm_pf0"
> + * @PCI_TSM_MFD: function0 of this device is "tsm_pf0"
Double space after "is" seems odd.
> + * @PCI_TSM_DOWNSTREAM: immediate Upstream Port of this device is "tsm_pf0"
> + */
> +enum pci_tsm_type {
> + PCI_TSM_INVALID,
> + PCI_TSM_PF0,
> + PCI_TSM_VIRTFN,
> + PCI_TSM_MFD,
> + PCI_TSM_DOWNSTREAM,
> +};
> +
> +/**
> + * struct pci_tsm - Core TSM context for a given PCIe endpoint
> + * @pdev: indicates the type of pci_tsm object
How does a pci_dev indicate a type? Maybe: Used to distinguish the type of pci_tsm object.
> + * @type: pci_tsm object type to disambiguate PCI_TSM_DOWNSTREAM and PCI_TSM_PF0
> + *
> + * This structure is wrapped by a low level TSM driver and returned by
> + * tsm_ops.probe(), it is freed by tsm_ops.remove(). Depending on
> + * whether @pdev is physical function 0, another physical function, or a
> + * virtual function determines the pci_tsm object type. E.g. see 'struct
> + * pci_tsm_pf0'.
> + */
> +struct pci_tsm {
> + struct pci_dev *pdev;
> + enum pci_tsm_type type;
> +};
> +
> +/**
> + * struct pci_tsm_pf0 - Physical Function 0 TDISP context
Missing tsm and kernel-doc warns if docs are complete.
> + * @state: reflect device initialized, connected, or bound
> + * @lock: protect @state vs pci_tsm_ops invocation
> + * @doe_mb: PCIe Data Object Exchange mailbox
> + */
> +struct pci_tsm_pf0 {
> + struct pci_tsm tsm;
> + enum pci_tsm_state state;
> + struct mutex lock;
> + struct pci_doe_mb *doe_mb;
> +};
next prev parent reply other threads:[~2025-06-17 12:51 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 5:47 [PATCH v3 00/13] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-05-16 5:47 ` [PATCH v3 01/13] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-06-02 13:18 ` Jason Gunthorpe
2025-06-04 0:42 ` Dan Williams
2025-06-04 1:15 ` Dan Williams
2025-06-04 12:15 ` Jason Gunthorpe
2025-06-04 12:14 ` Jason Gunthorpe
2025-06-06 3:33 ` Alexey Kardashevskiy
2025-06-06 2:09 ` Alexey Kardashevskiy
2025-05-16 5:47 ` [PATCH v3 02/13] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-06-17 12:16 ` Jonathan Cameron
2025-07-12 22:31 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 03/13] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2025-05-21 15:32 ` Aneesh Kumar K.V
2025-06-03 19:53 ` Dan Williams
2025-06-04 8:04 ` Aneesh Kumar K.V
2025-06-17 12:51 ` Jonathan Cameron [this message]
2025-07-12 22:07 ` dan.j.williams
2025-08-26 1:31 ` Alexey Kardashevskiy
2025-08-26 23:54 ` dan.j.williams
2025-08-27 4:44 ` Alexey Kardashevskiy
2025-08-28 19:27 ` dan.j.williams
2025-08-26 3:08 ` Alexey Kardashevskiy
2025-08-26 23:58 ` dan.j.williams
2025-08-27 5:06 ` Alexey Kardashevskiy
2025-08-26 10:22 ` Alexey Kardashevskiy
2025-08-27 0:15 ` dan.j.williams
2025-08-27 5:02 ` Alexey Kardashevskiy
2025-08-28 19:32 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 04/13] PCI: Enable host-bridge emulation for PCI_DOMAINS_GENERIC platforms Dan Williams
2025-05-16 5:47 ` [PATCH v3 05/13] PCI: vmd: Switch to pci_bus_find_emul_domain_nr() Dan Williams
2025-05-16 5:47 ` [PATCH v3 06/13] samples/devsec: Introduce a PCI device-security bus + endpoint sample Dan Williams
2025-06-17 13:30 ` Jonathan Cameron
2025-07-13 1:58 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 07/13] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-06-17 13:36 ` Jonathan Cameron
2025-05-16 5:47 ` [PATCH v3 08/13] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-06-17 14:04 ` Jonathan Cameron
2025-07-14 18:25 ` dan.j.williams
2025-07-03 2:59 ` Alexey Kardashevskiy
2025-05-16 5:47 ` [PATCH v3 09/13] PCI/IDE: Report available IDE streams Dan Williams
2025-05-18 12:48 ` kernel test robot
2025-06-17 14:16 ` Jonathan Cameron
2025-07-14 20:16 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 10/13] PCI/TSM: Report active " Dan Williams
2025-06-17 14:21 ` Jonathan Cameron
2025-07-14 20:49 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 11/13] samples/devsec: Add sample IDE establishment Dan Williams
2025-06-17 14:26 ` Jonathan Cameron
2025-07-14 20:59 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver Dan Williams
2025-05-16 6:52 ` Xu Yilun
2025-05-20 7:17 ` Aneesh Kumar K.V
2025-05-21 9:35 ` Xu Yilun
2025-05-26 5:05 ` Aneesh Kumar K.V
2025-05-26 7:52 ` Alexey Kardashevskiy
2025-05-26 15:44 ` Aneesh Kumar K.V
2025-05-27 1:01 ` Alexey Kardashevskiy
2025-05-27 11:48 ` Aneesh Kumar K.V
2025-05-27 13:06 ` Jason Gunthorpe
2025-05-27 14:26 ` Aneesh Kumar K.V
2025-05-27 14:45 ` Jason Gunthorpe
2025-05-28 12:17 ` Aneesh Kumar K.V
2025-05-28 16:42 ` Jason Gunthorpe
2025-05-28 16:52 ` Jason Gunthorpe
2025-05-29 9:30 ` Xu Yilun
2025-05-29 13:43 ` Aneesh Kumar K.V
2025-05-29 14:09 ` Jason Gunthorpe
2025-05-30 3:00 ` Alexey Kardashevskiy
2025-05-30 13:21 ` Jason Gunthorpe
2025-05-29 13:49 ` Xu Yilun
2025-05-29 14:05 ` Jason Gunthorpe
2025-05-29 3:03 ` Alexey Kardashevskiy
2025-05-29 13:34 ` Aneesh Kumar K.V
2025-05-29 13:37 ` [RFC PATCH 1/3] coco: tsm: Add tsm_bind/unbind helpers Aneesh Kumar K.V (Arm)
2025-05-29 13:37 ` [RFC PATCH 2/3] iommufd/viommu: Add support to associate viommu with kvm instance Aneesh Kumar K.V (Arm)
2025-05-29 14:13 ` Jason Gunthorpe
2025-05-29 13:37 ` [RFC PATCH 3/3] iommufd/tsm: Add tsm_bind/unbind iommufd ioctls Aneesh Kumar K.V (Arm)
2025-05-29 14:32 ` Jason Gunthorpe
2025-05-30 8:33 ` Aneesh Kumar K.V
2025-05-30 18:18 ` Jason Gunthorpe
2025-05-31 16:25 ` Xu Yilun
2025-06-02 4:52 ` Alexey Kardashevskiy
2025-06-02 17:17 ` Xu Yilun
2025-06-04 1:47 ` Alexey Kardashevskiy
2025-06-04 5:02 ` Xu Yilun
2025-06-04 12:37 ` Jason Gunthorpe
2025-06-06 15:40 ` Xu Yilun
2025-06-06 16:34 ` Jason Gunthorpe
2025-06-09 4:47 ` Xu Yilun
2025-06-02 11:08 ` Aneesh Kumar K.V
2025-06-02 16:25 ` Xu Yilun
2025-06-02 16:48 ` Jason Gunthorpe
2025-06-03 4:05 ` Xu Yilun
2025-06-03 12:11 ` Jason Gunthorpe
2025-06-04 5:58 ` Xu Yilun
2025-06-04 12:36 ` Jason Gunthorpe
2025-06-05 3:05 ` Xu Yilun
2025-06-10 7:05 ` Alexey Kardashevskiy
2025-06-10 18:19 ` Jason Gunthorpe
2025-06-11 1:26 ` Alexey Kardashevskiy
2025-06-10 4:47 ` Alexey Kardashevskiy
2025-06-10 18:21 ` Jason Gunthorpe
2025-06-12 4:15 ` Xu Yilun
2025-06-03 5:00 ` Aneesh Kumar K.V
2025-06-03 10:50 ` Xu Yilun
2025-06-03 12:14 ` Jason Gunthorpe
2025-06-04 5:31 ` Xu Yilun
2025-06-04 12:31 ` Jason Gunthorpe
2025-06-05 3:25 ` Xu Yilun
2025-06-05 14:54 ` Jason Gunthorpe
2025-06-09 6:10 ` Xu Yilun
2025-06-09 16:42 ` Suzuki K Poulose
2025-06-09 18:07 ` Jason Gunthorpe
2025-06-10 7:31 ` Alexey Kardashevskiy
2025-06-12 5:44 ` Xu Yilun
2025-06-03 12:18 ` Jason Gunthorpe
2025-06-04 1:06 ` Dan Williams
2025-06-04 12:18 ` Jason Gunthorpe
2025-06-02 12:47 ` Jason Gunthorpe
2025-06-03 3:47 ` Xu Yilun
2025-06-03 12:08 ` Jason Gunthorpe
2025-06-04 6:39 ` Xu Yilun
2025-06-04 12:39 ` Jason Gunthorpe
2025-06-05 1:56 ` Xu Yilun
2025-07-15 10:29 ` Xu Yilun
2025-07-15 13:09 ` Jason Gunthorpe
2025-07-16 15:41 ` Xu Yilun
2025-07-16 16:31 ` Jason Gunthorpe
2025-07-17 8:28 ` Xu Yilun
2025-07-17 12:43 ` Jason Gunthorpe
2025-07-18 9:15 ` Xu Yilun
2025-07-18 12:26 ` Jason Gunthorpe
2025-07-20 2:37 ` Xu Yilun
2025-05-30 2:44 ` [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver Alexey Kardashevskiy
2025-05-27 10:25 ` Suzuki K Poulose
2025-06-03 22:47 ` Dan Williams
2025-06-04 1:35 ` Alexey Kardashevskiy
2025-06-04 1:52 ` Dan Williams
2025-06-04 1:54 ` Dan Williams
2025-06-05 10:56 ` Alexey Kardashevskiy
2025-06-07 1:56 ` Dan Williams
2025-06-11 4:40 ` Alexey Kardashevskiy
2025-06-13 3:06 ` Dan Williams
2025-06-03 22:40 ` Dan Williams
2025-05-19 10:20 ` Alexey Kardashevskiy
2025-05-20 20:12 ` Dan Williams
2025-05-21 9:28 ` Xu Yilun
2025-05-26 8:08 ` Alexey Kardashevskiy
2025-05-29 14:20 ` Xu Yilun
2025-05-30 2:54 ` Alexey Kardashevskiy
2025-05-31 15:26 ` Xu Yilun
2025-06-02 4:51 ` Alexey Kardashevskiy
2025-06-02 18:51 ` Xu Yilun
2025-06-03 19:12 ` Dan Williams
2025-07-07 7:17 ` Aneesh Kumar K.V
2025-05-20 5:20 ` Aneesh Kumar K.V
2025-05-20 21:12 ` Dan Williams
2025-05-16 5:47 ` [PATCH v3 13/13] PCI/TSM: Add Guest TSM Support Dan Williams
2025-05-19 10:20 ` Alexey Kardashevskiy
2025-05-20 21:11 ` Dan Williams
2025-05-22 4:07 ` Alexey Kardashevskiy
2025-06-03 22:26 ` Dan Williams
2025-06-03 22:33 ` Jason Gunthorpe
2025-06-10 8:31 ` Alexey Kardashevskiy
2025-07-11 23:04 ` dan.j.williams
2025-05-20 9:25 ` Aneesh Kumar K.V
2025-05-20 21:27 ` Dan Williams
2025-05-20 11:00 ` Aneesh Kumar K.V
2025-05-20 21:31 ` Dan Williams
2025-06-03 19:07 ` Dan Williams
2025-05-21 15:03 ` Xu Yilun
2025-06-03 19:20 ` 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=20250617135145.0000376b@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.com \
--cc=suzuki.poulose@arm.com \
--cc=yilun.xu@linux.intel.com \
--cc=zhiw@nvidia.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 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.