[{"id":3688704,"web_url":"http://patchwork.ozlabs.org/comment/3688704/","msgid":"<20260508200351.D3E20C2BCB0@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T20:03:51","subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:\n- [High] UAPI Backwards Compatibility Breakage and Buffer Overflow Risk\n- [High] Missing memory_lock Causes Hardware State Races During Reset\n- [Medium] UAPI Bloat / Bypassing VFIO_DEVICE_FEATURE Framework\n- [Medium] Incorrect Module Parameter Scope Limits Vendor Drivers\n--\n\ncommit 83318520665fc31c05135b8adff081970464291e\nAuthor: Chengwen Feng \n\nvfio/pci: Add PCIe TPH interface with capability query\n \nAdd VFIO_DEVICE_PCI_TPH IOCTL to allow userspace to query device TPH\ncapabilities, supported modes, and steering tag table information.\n\n> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c\n> index 0c771064c0b84..40bf5aa9fd0be 100644\n> --- a/drivers/vfio/pci/vfio_pci.c\n> +++ b/drivers/vfio/pci/vfio_pci.c\n> @@ -60,6 +60,12 @@ static bool disable_denylist;\n> module_param(disable_denylist, bool, 0444);\n> MODULE_PARM_DESC(disable_denylist, \"Disable use of device denylist. Disabling the denylist allows binding to devices with known errata that may lead to exploitable stability or security issues when accessed by untrusted users.\");\n> \n> +#ifdef CONFIG_PCIE_TPH\n> +static bool enable_unsafe_tph_ds_mode;\n> +module_param(enable_unsafe_tph_ds_mode, bool, 0444);\n\nVendor-specific VFIO drivers (such as mlx5_vfio_pci or hisi_vfio_pci) load\nthe shared vfio_pci_core.ko library directly and do not depend on vfio_pci.ko.\n\nIf users of these vendor drivers want to enable unsafe TPH DS mode, they\nhave no way to do so unless they explicitly load the generic vfio_pci driver,\nwhich alters the core state for all bound devices.\n\nShould this parameter reside directly in vfio_pci_core.c instead?\n\n[ ... ]\n\n> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n> index 3f8d093aacf8a..0e97b128fd637 100644\n> --- a/drivers/vfio/pci/vfio_pci_core.c\n> +++ b/drivers/vfio/pci/vfio_pci_core.c\n[ ... ]\n> @@ -1461,6 +1463,54 @@ static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,\n> \t\t\t\t ioeventfd.fd);\n> }\n> \n> +static int vfio_pci_tph_get_cap(struct vfio_pci_core_device *vdev,\n> +\t\t\t\tstruct vfio_device_pci_tph_op *op,\n> +\t\t\t\tvoid __user *uarg)\n> +{\n> +\tstruct pci_dev *pdev = vdev->pdev;\n> +\tstruct vfio_pci_tph_cap cap = {0};\n> +\tu8 mode;\n> +\n> +\tif (op->argsz < offsetofend(struct vfio_device_pci_tph_op, cap))\n> +\t\treturn -EINVAL;\n\nIf struct vfio_pci_tph_cap is extended in future kernel releases, offsetofend()\nwill increase. Will new kernels reject valid requests from older userspace\nbinaries with -EINVAL, breaking backwards compatibility?\n\n> +\n> +\tmode = pcie_tph_get_st_modes(pdev);\n> +\t/* Hide unsafe device-specific (DS) mode by default */\n> +\tif (!enable_unsafe_tph_ds_mode)\n> +\t\tmode &= ~PCI_TPH_CAP_ST_DS;\n> +\tif (mode == 0 || mode == PCI_TPH_CAP_ST_NS)\n> +\t\treturn -EOPNOTSUPP;\n> +\n> +\tif (mode & PCI_TPH_CAP_ST_IV)\n> +\t\tcap.supported_modes |= VFIO_PCI_TPH_MODE_IV;\n> +\tif (mode & PCI_TPH_CAP_ST_DS)\n> +\t\tcap.supported_modes |= VFIO_PCI_TPH_MODE_DS;\n> +\tcap.st_table_sz = pcie_tph_get_st_table_size(pdev);\n> +\n> +\tif (copy_to_user(uarg, &cap, sizeof(cap)))\n\nIf the capability structure grows in the future, will the kernel write beyond\nthe bounds of an older userspace application's allocated buffer?\n\n> +\t\treturn -EFAULT;\n> +\n> +\treturn 0;\n> +}\n> +\n> +static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,\n> +\t\t\t void __user *uarg)\n> +{\n> +\tstruct vfio_device_pci_tph_op op = {0};\n> +\tsize_t minsz = sizeof(op.argsz) + sizeof(op.op);\n> +\n> +\tif (copy_from_user(&op, uarg, minsz))\n> +\t\treturn -EFAULT;\n> +\n> +\tswitch (op.op) {\n> +\tcase VFIO_PCI_TPH_GET_CAP:\n> +\t\treturn vfio_pci_tph_get_cap(vdev, &op, uarg + minsz);\n\nThis handler does not acquire down_read(&vdev->memory_lock). Does this allow\nTPH IOCTLs to run concurrently with a PCI hot reset\n(VFIO_DEVICE_PCI_HOT_RESET) which takes the write lock via\nvfio_pci_zap_and_down_write_memory_lock()?\n\nConcurrent execution could allow vfio_pci_tph_get_cap() to read configuration\nspace while the secondary bus is in reset, yielding bogus data.\n\nMore importantly, later in this series when vfio_pci_tph_set_st() is added to\nwrite directly to the MSI-X table via MMIO, performing MMIO writes to a device\nactively undergoing reset can cause PCI Master Aborts. On certain platforms,\nthis can trigger AER panics or EEH isolation.\n\n[ ... ]\n> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> index 5de618a3a5eee..81da2bd0c21b0 100644\n> --- a/include/uapi/linux/vfio.h\n> +++ b/include/uapi/linux/vfio.h\n[ ... ]\n> +/**\n> + * VFIO_DEVICE_PCI_TPH - _IO(VFIO_TYPE, VFIO_BASE + 22)\n> + *\n> + * IOCTL for managing PCIe TLP Processing Hints (TPH) on\n> + * a VFIO-assigned PCI device. Provides operations to query\n> + * device capabilities, enable/disable TPH, retrieve CPU's\n> + * steering tags, and program steering tag tables.\n> + *\n> + * Return: 0 on success, negative errno on failure.\n> + * -EOPNOTSUPP: Operation not supported\n> + * -ENODEV: Device or required functionality not present\n> + * -EINVAL: Invalid argument or TPH not supported\n> + */\n> +#define VFIO_DEVICE_PCI_TPH\t_IO(VFIO_TYPE, VFIO_BASE + 22)\n\nThis introduces a new top-level IOCTL to manage PCIe TPH capabilities instead\nof using the standard VFIO_DEVICE_FEATURE IOCTL.\n\nCould this be implemented using VFIO_DEVICE_FEATURE, which was explicitly\ndesigned to act as a unified multiplexer for querying and setting new device\nfeatures, to avoid unnecessarily bloating the UAPI namespace and duplicating\nboilerplate for sizing and feature discovery?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=QKzwgDzb;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-54284-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"QKzwgDzb\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gC0SF6WgVz1yK7\n\tfor ; Sat, 09 May 2026 06:03:57 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 4A53F300B1F0\n\tfor ; Fri, 8 May 2026 20:03:55 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8AB2C3101C0;\n\tFri, 8 May 2026 20:03:52 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 65FD22F0680\n\tfor ; Fri, 8 May 2026 20:03:52 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D3E20C2BCB0;\n\tFri, 8 May 2026 20:03:51 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778270632; cv=none;\n b=gTGJJ844pOpDOS6e3Z4hR+6ZEDEr+VCZNnaB/IPIjDkMvBU4xGK3sOfzVOn+Gn6fQpWCWGl2gAFrjEd0BRFMaBvHgLVieN5JJp8lxxhJ+iG+xhovpik/rdi3Nmh7tcJhMiLwEdcb1etP6+qcXnPERrtxq4LjDXnM4oN4WYOACho=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778270632; c=relaxed/simple;\n\tbh=l59vJd2IC/wcrjIDYyYhP5FAMAaAYWBdyRI+ajevnOU=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=WBxIUcZVqfTK9jPdT8MkNZN14d4DZGvo1cIEbMxZIJB4cKuacTWRa4zqTItES1SROSSwGoQddoMXZbZzVX1GznDlTHyx1thZhmgGPzCnTBS+lZSBFjYpDIcTb1AYvhhngIViKrXnzjKx7ncwaZjbYafxuAbO7qN7O+vUs4qouVc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=QKzwgDzb; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778270632;\n\tbh=l59vJd2IC/wcrjIDYyYhP5FAMAaAYWBdyRI+ajevnOU=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=QKzwgDzbtLZw6YjxdW9K1AzLoI0no4HmIaGM6SsKLlb2tx0QZoEZRRS42MBAb7NoZ\n\t mc4nX2mb/CXmXb6gTBUphdl85yeNNSWcTWCE799Y1gwatgiSMzOdL+ofiVQC1qMgDE\n\t JMQQtxmSt7AwQuVKGS8etO5Qqdyi66vepEJ4zAnim2BMtqam0tFyjA8KW4vRbXdl7w\n\t y1bVruuXurCoQuie3f5E34ikkypZcMBG/LOoI2u5LPc8PTgk/XAXcCYApsl7ynUHQO\n\t NX6Zhkki/RTKLLQM3GDvHR/LltdImZJgbXiCHXLDpLsbhAdy3LIb+mTNLXE+2hWqCJ\n\t jh9Ns/8+FINIA==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","Reply-To":"sashiko@lists.linux.dev","To":"\"Chengwen Feng\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508064053.37529-5-fengchengwen@huawei.com>","References":"<20260508064053.37529-5-fengchengwen@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 20:03:51 +0000","Message-Id":"<20260508200351.D3E20C2BCB0@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}},{"id":3688754,"web_url":"http://patchwork.ozlabs.org/comment/3688754/","msgid":"<20260508164003.70918c0c@shazbot.org>","list_archive_url":null,"date":"2026-05-08T22:40:03","subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","submitter":{"id":91887,"url":"http://patchwork.ozlabs.org/api/people/91887/","name":"Alex Williamson","email":"alex@shazbot.org"},"content":"On Fri, 8 May 2026 14:40:50 +0800\nChengwen Feng wrote:\n\n> Add VFIO_DEVICE_PCI_TPH IOCTL to allow userspace to query device TPH\n> capabilities, supported modes, and steering tag table information.\n> \n> Add module parameter 'enable_unsafe_tph_ds_mode' to restrict unsafe\n> device-specific TPH mode to trusted userspace only.\n> \n> Signed-off-by: Chengwen Feng \n> ---\n> drivers/vfio/pci/vfio_pci.c | 13 ++-\n> drivers/vfio/pci/vfio_pci_core.c | 56 ++++++++++++-\n> include/linux/vfio_pci_core.h | 3 +-\n> include/uapi/linux/vfio.h | 133 +++++++++++++++++++++++++++++++\n> 4 files changed, 202 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c\n> index 0c771064c0b8..40bf5aa9fd0b 100644\n> --- a/drivers/vfio/pci/vfio_pci.c\n> +++ b/drivers/vfio/pci/vfio_pci.c\n> @@ -60,6 +60,12 @@ static bool disable_denylist;\n> module_param(disable_denylist, bool, 0444);\n> MODULE_PARM_DESC(disable_denylist, \"Disable use of device denylist. Disabling the denylist allows binding to devices with known errata that may lead to exploitable stability or security issues when accessed by untrusted users.\");\n> \n> +#ifdef CONFIG_PCIE_TPH\n> +static bool enable_unsafe_tph_ds_mode;\n> +module_param(enable_unsafe_tph_ds_mode, bool, 0444);\n> +MODULE_PARM_DESC(enable_unsafe_tph_ds_mode, \"Enable UNSAFE TPH device-specific (DS) mode. This mode provides weak isolation, cannot be safely used for virtual machines. If you do not know what this is for, step away. (default: false)\");\n> +#endif\n> +\n\nWhy is the \"unsafe\" aspect of this keyed on mode rather than storage\nlocation?\n\nCurrently the user cannot enable TPH, the capability is read-only, but\nthe user does have direct access to the MSI-X table. We rely on an\nagreement that the user needs to use SET_IRQS to allocate host vectors\nand we use interrupt remapping as protection against abuse, but there's\nno mediation of STs written directly to the MSI-X table. If the device\nsupports IV mode with ST in the MSI-X table, nothing prevents the user\nfrom writing those ST entries directly to the MSI-X table. Therefore\ndoesn't it have the same security concern as DS mode?\n\nFurther, config space lives in the device and various devices are known\nto have alternate means for accessing their config space.\nVirtualization of config space is more to present the device in the VM\naddress space and bridge features between guest and host. It's not\ngreat as a security barrier.\n\nMaybe it's really neither the mode nor storage location, and we need to\ndecide if TPH as a whole introduces any new security considerations.\nIt seems arguable whether we can actually prevent a device from\nincluding arbitrary STs on TLPs in any case and maybe we're really only\nexposing a curated programming interface.\n\n...\n> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> index 5de618a3a5ee..81da2bd0c21b 100644\n> --- a/include/uapi/linux/vfio.h\n> +++ b/include/uapi/linux/vfio.h\n> @@ -1321,6 +1321,139 @@ struct vfio_precopy_info {\n> \n> #define VFIO_MIG_GET_PRECOPY_INFO _IO(VFIO_TYPE, VFIO_BASE + 21)\n> \n> +/**\n> + * struct vfio_pci_tph_cap - PCIe TPH capability information\n> + * @supported_modes: Supported TPH operating modes\n> + * @st_table_sz: Number of entries in ST table; 0 means no ST table\n> + * @reserved: Must be zero\n> + *\n> + * Used with VFIO_PCI_TPH_GET_CAP operation to return device\n> + * TLP Processing Hints (TPH) capabilities to userspace.\n> + */\n> +struct vfio_pci_tph_cap {\n> +\t__u8 supported_modes;\n> +#define VFIO_PCI_TPH_MODE_IV\t(1u << 0) /* Interrupt vector */\n> +#define VFIO_PCI_TPH_MODE_DS\t(1u << 1) /* Device specific */\n> +\t__u8 reserved0;\n> +\t__u16 st_table_sz;\n> +\t__u32 reserved;\n> +};\n> +\n> +/**\n> + * struct vfio_pci_tph_ctrl - TPH enable control structure\n> + * @mode: Selected TPH operating mode (VFIO_PCI_TPH_MODE_*)\n> + * @reserved: Must be zero\n> + *\n> + * Used with VFIO_PCI_TPH_ENABLE operation to specify the\n> + * operating mode when enabling TPH on the device.\n> + */\n> +struct vfio_pci_tph_ctrl {\n> +\t__u8 mode;\n> +\t__u8 reserved[7];\n> +};\n> +\n> +/**\n> + * struct vfio_pci_tph_entry - Single TPH steering tag entry\n> + * @cpu: CPU identifier for steering tag calculation\n> + * @mem_type: Memory type (VFIO_PCI_TPH_MEM_TYPE_*)\n> + * @reserved0: Must be zero\n> + * @index: ST table index for programming\n> + * @st: Unused for SET_ST\n> + * @reserved1: Must be zero\n> + *\n> + * For VFIO_PCI_TPH_GET_ST:\n> + * Userspace sets @cpu and @mem_type; kernel returns @st.\n> + *\n> + * For VFIO_PCI_TPH_SET_ST:\n> + * Userspace sets @index, @cpu, and @mem_type.\n> + * Kernel internally computes the steering tag and programs\n> + * it into the specified @index.\n> + *\n> + * If @cpu == U32_MAX, kernel clears the steering tag at\n> + * the specified @index.\n> + */\n> +struct vfio_pci_tph_entry {\n> +\t__u32 cpu;\n> +\t__u8 mem_type;\n> +#define VFIO_PCI_TPH_MEM_TYPE_VM\t0\n> +#define VFIO_PCI_TPH_MEM_TYPE_PM\t1\n> +\t__u8 reserved0;\n> +\t__u16 index;\n> +\t__u16 st;\n> +\t__u16 reserved1;\n> +};\n> +\n> +/**\n> + * struct vfio_pci_tph_st - Batch steering tag request\n> + * @count: Number of entries in the array\n> + * @reserved: Must be zero\n> + * @ents: Flexible array of steering tag entries\n> + *\n> + * Container structure for batch get/set operations.\n> + * Used with both VFIO_PCI_TPH_GET_ST and VFIO_PCI_TPH_SET_ST.\n> + */\n> +struct vfio_pci_tph_st {\n> +\t__u32 count;\n> +\t__u32 reserved;\n> +\tstruct vfio_pci_tph_entry ents[];\n> +#define VFIO_PCI_TPH_MAX_ENTRIES 2048\n> +};\n> +\n> +/**\n> + * struct vfio_device_pci_tph_op - Argument for VFIO_DEVICE_PCI_TPH\n> + * @argsz: User allocated size of this structure\n> + * @op: TPH operation (VFIO_PCI_TPH_*)\n> + * @cap: Capability data for GET_CAP\n> + * @ctrl: Control data for ENABLE\n> + * @st: Batch entry data for GET_ST/SET_ST\n> + *\n> + * @argsz must be set by the user to the size of the structure\n> + * being executed. Kernel validates input and returns data\n> + * only within the specified size.\n> + *\n> + * Operations:\n> + * - VFIO_PCI_TPH_GET_CAP: Query device TPH capabilities.\n> + * - VFIO_PCI_TPH_ENABLE: Enable TPH using mode from &ctrl.\n> + * - VFIO_PCI_TPH_DISABLE: Disable TPH on the device.\n> + * - VFIO_PCI_TPH_GET_ST: Retrieve CPU steering tags for Device-Specific (DS)\n> + * mode. Used when device requires SW to obtain ST\n> + * values for programming.\n> + * - VFIO_PCI_TPH_SET_ST: Program steering tag entries into device ST table.\n> + * Valid when ST table resides in TPH Requester\n> + * Capability or MSI-X Table.\n> + * If any entry fails, all programmed entries are rolled\n> + * back to 0 before returning error.\n> + */\n> +struct vfio_device_pci_tph_op {\n> +\t__u32 argsz;\n> +\t__u32 op;\n> +#define VFIO_PCI_TPH_GET_CAP\t0\n> +#define VFIO_PCI_TPH_ENABLE\t1\n> +#define VFIO_PCI_TPH_DISABLE\t2\n> +#define VFIO_PCI_TPH_GET_ST\t3\n> +#define VFIO_PCI_TPH_SET_ST\t4\n> +\tunion {\n> +\t\tstruct vfio_pci_tph_cap cap;\n> +\t\tstruct vfio_pci_tph_ctrl ctrl;\n> +\t\tstruct vfio_pci_tph_st st;\n> +\t};\n> +};\n> +\n> +/**\n> + * VFIO_DEVICE_PCI_TPH - _IO(VFIO_TYPE, VFIO_BASE + 22)\n> + *\n> + * IOCTL for managing PCIe TLP Processing Hints (TPH) on\n> + * a VFIO-assigned PCI device. Provides operations to query\n> + * device capabilities, enable/disable TPH, retrieve CPU's\n> + * steering tags, and program steering tag tables.\n> + *\n> + * Return: 0 on success, negative errno on failure.\n> + * -EOPNOTSUPP: Operation not supported\n> + * -ENODEV: Device or required functionality not present\n> + * -EINVAL: Invalid argument or TPH not supported\n> + */\n> +#define VFIO_DEVICE_PCI_TPH\t_IO(VFIO_TYPE, VFIO_BASE + 22)\n> +\n\nThis seems like the wrong shape to me and introduces yet another ioctl\nmultiplexer. We already have that via the device feature interface.\nI'd propose this only needs one new DEVICE_FEATURE ioctl, TPH_ST. The\nuAPI would look like:\n\nstruct vfio_device_feature_tph_st {\n\t__u32 flags;\n#define VFIO_TPH_ST_MEM_TYPE_PM\t(1 << 0)\n\t__u16 index;\n\t__u16 count;\n\t__u32 data[]; /* host CPU# on SET, ST value on GET */\n}\n\nThe user can SET multiple STs at once that have the same mem_type\n(assuming that's a reasonable limitation). On SET, each {cpu#,\nmem_type} is translated to a host value and stored internally. A GET\nreturns that translated ST value for DS use cases.\n\nThe user can use PROBE to determine if this feature is available.\n\nWe already provide the TPH capability read-only in config space, we can\nuse that rather than an explicit INFO/GET_CAP interface.\n\nWhen the feature is available, the TPH control register is virtualized.\nOn enabling TPH via config space, vfio will store the translated ST\nvalues to the appropriate location, or none, and enable TPH. On SET\nwhile already enabled, vfio will update both the internal table and the\ndevice location (or none). Thanks,\n\nAlex","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=shazbot.org header.i=@shazbot.org header.a=rsa-sha256\n header.s=fm2 header.b=Qm8ycKBe;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm3 header.b=lL6hewsN;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-54299-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=\"Qm8ycKBe\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"lL6hewsN\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.12.124.158","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=shazbot.org"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gC3wj4MFHz1yHW\n\tfor ; Sat, 09 May 2026 08:40:21 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id B60C130089AB\n\tfor ; Fri, 8 May 2026 22:40:17 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C270638A733;\n\tFri, 8 May 2026 22:40:14 +0000 (UTC)","from fhigh-b7-smtp.messagingengine.com\n (fhigh-b7-smtp.messagingengine.com [202.12.124.158])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 53618221DB3;\n\tFri, 8 May 2026 22:40:11 +0000 (UTC)","from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51])\n\tby mailfhigh.stl.internal (Postfix) with ESMTP id B60AF7A003D;\n\tFri, 8 May 2026 18:40:09 -0400 (EDT)","from phl-frontend-03 ([10.202.2.162])\n by phl-compute-11.internal (MEProxy); Fri, 08 May 2026 18:40:10 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Fri,\n 8 May 2026 18:40:06 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778280014; cv=none;\n b=VBdJsDPRM3dYpZksRwQRMyPb2ehuPjz9Aer25g/XeTk0l4SZiJHkeVskfQT366ZVG1LV9xPEQKQzWv6YGqKdWd80sFMs2lDygqDYNgy8MY8A4z7WkUd9L1ZJZqF7+fZdpK7KPF7WtGexHu0zOh6aEYpea2ockLKW+L38JUZkDaM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778280014; c=relaxed/simple;\n\tbh=3U/SufooL3Si7bLRcOBI7bsAVJzUk2gQOQr1d6uTwfg=;\n\th=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:\n\t MIME-Version:Content-Type;\n b=aybgsKnZwIvG1wbSR4dgL6BQHoK3OdV4vmijaohJlcfZ4cxVepfkoOLkIf6Lhe+8B2zWYNhR66UU+w955VVxMtZyPglu72vL+UzJymWgJhliOnDiF9p88wDalAk1+ykbN86CWw6jkxVXHupk8XVonShPG0Vrkp82B6rEodS0DVE=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org;\n spf=pass smtp.mailfrom=shazbot.org;\n dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=Qm8ycKBe;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=lL6hewsN; arc=none smtp.client-ip=202.12.124.158","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=shazbot.org; h=\n\tcc:cc:content-transfer-encoding:content-type:content-type:date\n\t:date:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to; s=fm2; t=1778280009;\n\t x=1778366409; bh=Wc3dTDrH7Vx3KTw/aznXnAyEe2c8FMx6eWi4Ve4R5S0=; b=\n\tQm8ycKBeS1hGwW4e+I7uIEDcACwNCXjMVDUrfqyJJNCYwNCXNVsanULGcKUWUWbu\n\taLqHiK5YvlbJizCgxig8xYSyMaR/cZDDQjz6x4d9ZtCOu9zONtVWgL6ITwoCk9p/\n\tR48xsEfaSzKi8DyOdn4IHlfQbaoQ6WVpez4WOIhOaIrpBlqcGQGJm+Y2BYue5j4n\n\tVWuLST1sOUqfB/RxQHKLv8e4T4D98sqiHcpvGYAzedddYNqzgs8yqHIoQJpgKJPe\n\tvkbLwvGnkIKYqSEJXkHoifywkIM4BiXxG1BTCyEz4fv47B53lhhICD3YeMFlY7p6\n\tVYxTNfKNb134qchlDU/Kdw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:cc:content-transfer-encoding\n\t:content-type:content-type:date:date:feedback-id:feedback-id\n\t:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to:x-me-proxy\n\t:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1778280009; x=\n\t1778366409; bh=Wc3dTDrH7Vx3KTw/aznXnAyEe2c8FMx6eWi4Ve4R5S0=; b=l\n\tL6hewsNFVW7fn722npCcf241T/bS42PLlQmu61d8YKU/gA2VR3jS09oQ6/ZH88qB\n\t+Hf6KJJ/IJTtDSYwfsyyVm0ofC/czvL+Mt0CQjuJC78Tdtjm3sWwiNHWFuSCytCr\n\t3Y4XUbcM48AWldIygn8RlkOiIDyqao1Y5Itie7YHGQLqMkU8q14a1UUj60w1zoFL\n\tCD3RW8K7/lVej1QaqxaHxaJz37FpX4XRh1ux9ByrN8Hlw9UvVaE0dFSZOMQCdqAu\n\tuUUXSEtFchMMS0RVQVg4eFIx0O81LAYVcwvXGeEtXIsCqlf1oaUEMxo3CG8taYeY\n\t726HIuxZXA4auP6NAVpnA=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduudduheejucetufdoteggodetrf\n dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu\n rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf\n gurhepfffhvfevuffkjghfofggtgfgsehtjeertdertddvnecuhfhrohhmpeetlhgvgicu\n hghilhhlihgrmhhsohhnuceorghlvgigsehshhgriigsohhtrdhorhhgqeenucggtffrrg\n htthgvrhhnpedvkeefjeekvdduhfduhfetkedugfduieettedvueekvdehtedvkefgudeg\n veeuueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe\n grlhgvgiesshhhrgiisghothdrohhrghdpnhgspghrtghpthhtohepuddupdhmohguvgep\n shhmthhpohhuthdprhgtphhtthhopehfvghnghgthhgvnhhgfigvnheshhhurgifvghird\n gtohhmpdhrtghpthhtohepjhhgghesiihivghpvgdrtggrpdhrtghpthhtohepfigrthhh\n shgrlhgrrdhvihhthhgrnhgrghgvsegrrhhmrdgtohhmpdhrtghpthhtohephhgvlhhgrg\n grsheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepfigvihdrhhhurghnghdvsegrmhgu\n rdgtohhmpdhrtghpthhtohepfigrnhhgiihhohhuudeshhhishhilhhitghonhdrtghomh\n dprhgtphhtthhopeifrghnghihuhhshhgrnhduvdeshhhurgifvghirdgtohhmpdhrtghp\n thhtoheplhhiuhihohhnghhlohhngheshhhurgifvghirdgtohhmpdhrtghpthhtohepkh\n hvmhesvhhgvghrrdhkvghrnhgvlhdrohhrgh","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"i03f14258:Fastmail","Date":"Fri, 8 May 2026 16:40:03 -0600","From":"Alex Williamson ","To":"Chengwen Feng ","Cc":", , ,\n , , ,\n , ,\n , alex@shazbot.org","Subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","Message-ID":"<20260508164003.70918c0c@shazbot.org>","In-Reply-To":"<20260508064053.37529-5-fengchengwen@huawei.com>","References":"<20260508064053.37529-1-fengchengwen@huawei.com>\n\t<20260508064053.37529-5-fengchengwen@huawei.com>","X-Mailer":"Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":3688804,"web_url":"http://patchwork.ozlabs.org/comment/3688804/","msgid":"","list_archive_url":null,"date":"2026-05-09T03:28:03","subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","submitter":{"id":92756,"url":"http://patchwork.ozlabs.org/api/people/92756/","name":"fengchengwen","email":"fengchengwen@huawei.com"},"content":"On 5/9/2026 6:40 AM, Alex Williamson wrote:\n> On Fri, 8 May 2026 14:40:50 +0800\n> Chengwen Feng wrote:\n> \n>> Add VFIO_DEVICE_PCI_TPH IOCTL to allow userspace to query device TPH\n>> capabilities, supported modes, and steering tag table information.\n>>\n>> Add module parameter 'enable_unsafe_tph_ds_mode' to restrict unsafe\n>> device-specific TPH mode to trusted userspace only.\n>>\n>> Signed-off-by: Chengwen Feng \n>> ---\n>> drivers/vfio/pci/vfio_pci.c | 13 ++-\n>> drivers/vfio/pci/vfio_pci_core.c | 56 ++++++++++++-\n>> include/linux/vfio_pci_core.h | 3 +-\n>> include/uapi/linux/vfio.h | 133 +++++++++++++++++++++++++++++++\n>> 4 files changed, 202 insertions(+), 3 deletions(-)\n>>\n>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c\n>> index 0c771064c0b8..40bf5aa9fd0b 100644\n>> --- a/drivers/vfio/pci/vfio_pci.c\n>> +++ b/drivers/vfio/pci/vfio_pci.c\n>> @@ -60,6 +60,12 @@ static bool disable_denylist;\n>> module_param(disable_denylist, bool, 0444);\n>> MODULE_PARM_DESC(disable_denylist, \"Disable use of device denylist. Disabling the denylist allows binding to devices with known errata that may lead to exploitable stability or security issues when accessed by untrusted users.\");\n>> \n>> +#ifdef CONFIG_PCIE_TPH\n>> +static bool enable_unsafe_tph_ds_mode;\n>> +module_param(enable_unsafe_tph_ds_mode, bool, 0444);\n>> +MODULE_PARM_DESC(enable_unsafe_tph_ds_mode, \"Enable UNSAFE TPH device-specific (DS) mode. This mode provides weak isolation, cannot be safely used for virtual machines. If you do not know what this is for, step away. (default: false)\");\n>> +#endif\n>> +\n> \n> Why is the \"unsafe\" aspect of this keyed on mode rather than storage\n> location?\n> \n> Currently the user cannot enable TPH, the capability is read-only, but\n> the user does have direct access to the MSI-X table. We rely on an\n> agreement that the user needs to use SET_IRQS to allocate host vectors\n> and we use interrupt remapping as protection against abuse, but there's\n> no mediation of STs written directly to the MSI-X table. If the device\n> supports IV mode with ST in the MSI-X table, nothing prevents the user\n> from writing those ST entries directly to the MSI-X table. Therefore\n> doesn't it have the same security concern as DS mode?\n\n\nAgree, from this perspective, even if it is in MSI-X table, it is still unsafe.\nSo TPH is unsafe as a whole, not just DS mode.\n\n> \n> Further, config space lives in the device and various devices are known\n> to have alternate means for accessing their config space.\n> Virtualization of config space is more to present the device in the VM\n> address space and bridge features between guest and host. It's not\n> great as a security barrier.\n> \n> Maybe it's really neither the mode nor storage location, and we need to\n> decide if TPH as a whole introduces any new security considerations.\n\nI will adjust the module parameter to control TPH globally instead of only DS mode.\n\n> It seems arguable whether we can actually prevent a device from\n> including arbitrary STs on TLPs in any case and maybe we're really only\n> exposing a curated programming interface.\n> \n> ...\n>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n>> index 5de618a3a5ee..81da2bd0c21b 100644\n>> --- a/include/uapi/linux/vfio.h\n>> +++ b/include/uapi/linux/vfio.h\n\n...\n\n>> +#define VFIO_DEVICE_PCI_TPH\t_IO(VFIO_TYPE, VFIO_BASE + 22)\n>> +\n> \n> This seems like the wrong shape to me and introduces yet another ioctl\n> multiplexer. We already have that via the device feature interface.\n> I'd propose this only needs one new DEVICE_FEATURE ioctl, TPH_ST. The\n> uAPI would look like:\n> \n> struct vfio_device_feature_tph_st {\n> \t__u32 flags;\n> #define VFIO_TPH_ST_MEM_TYPE_PM\t(1 << 0)\n> \t__u16 index;\n> \t__u16 count;\n> \t__u32 data[]; /* host CPU# on SET, ST value on GET */\n> }\n> \n> The user can SET multiple STs at once that have the same mem_type\n> (assuming that's a reasonable limitation). On SET, each {cpu#,\n\nAgree, using the same mem_type for a batch is a good idea.\n\nBecause it could set multiple index, so how about:\n\nstruct vfio_pci_tph_entry {\n\t__u32 cpu;\n\t__u16 val;\t/* ST index on SET, ST value on GET */\n\t__u16 reserved;\n}\n\nstruct vfio_device_feature_tph_st {\n\t__u32 op;\n#define VFIO_TPH_OP_GET_ST\t0\n#define VFIO_TPH_OP_SET_ST\t1\n\t__u32 flags;\n#define VFIO_TPH_ST_MEM_TYPE_PM\t(1 << 0)\n\t__u16 count;\n\t__u16 reserved1;\n\tstruct vfio_pci_tph_entry ents[];\n}\n\n> mem_type} is translated to a host value and stored internally. A GET\n\nShould we store internally? How about writing directly to the device?\n\n> returns that translated ST value for DS use cases.\n> \n> The user can use PROBE to determine if this feature is available.\n> \n> We already provide the TPH capability read-only in config space, we can\n> use that rather than an explicit INFO/GET_CAP interface.\n\nOK\n\n> \n> When the feature is available, the TPH control register is virtualized.\n> On enabling TPH via config space, vfio will store the translated ST\n> values to the appropriate location, or none, and enable TPH. On SET\n> while already enabled, vfio will update both the internal table and the\n> device location (or none). Thanks,\n> \n> Alex","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256\n header.s=dkim header.b=3xqneVsJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-54308-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com\n header.b=\"3xqneVsJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=113.46.200.216","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=huawei.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=huawei.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gCBK2426sz1yCg\n\tfor ; Sat, 09 May 2026 13:28:22 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 843F630180AD\n\tfor ; Sat, 9 May 2026 03:28:17 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 6C85133F59D;\n\tSat, 9 May 2026 03:28:16 +0000 (UTC)","from canpmsgout01.his.huawei.com (canpmsgout01.his.huawei.com\n [113.46.200.216])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 42B3618A92F;\n\tSat, 9 May 2026 03:28:13 +0000 (UTC)","from mail.maildlp.com (unknown [172.19.163.0])\n\tby canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4gCB7x3qHgz1T4Hv;\n\tSat, 9 May 2026 11:20:29 +0800 (CST)","from kwepemk500009.china.huawei.com (unknown [7.202.194.94])\n\tby mail.maildlp.com (Postfix) with ESMTPS id D910040537;\n\tSat, 9 May 2026 11:28:04 +0800 (CST)","from [10.67.121.161] (10.67.121.161) by\n kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.1544.11; Sat, 9 May 2026 11:28:04 +0800"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778297296; cv=none;\n b=lm8lAzAJNFAVpyHVO+tW1Nw7MBrov5OBVGVfswlmz+jnaRu31HfxZellvM5OLgljUNmcDHFstqbnTQJl2LZGytJnSltCN+fQGnMRb8g6roc/4W6fdQrFyxc4cR2vLBwPNcwv/kjM/QWAaIhp9bVQvddPWxSq/Kfi3HTXJgI1PE8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778297296; c=relaxed/simple;\n\tbh=+g3LVpLAIYtG7MRn5pLcltFaa760xW206BEeENAcrqY=;\n\th=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:\n\t In-Reply-To:Content-Type;\n b=bhoyMPtqbeO9D5jYuHEgpo6LV09vnPqjyx0xlVp94FE3hZEXb3ryax5e2muv03jMGHuX7+gzbp2h0B8E7jVUyjAiVbuPIOKwGxK5kOEALACTd+c6hlOiPnfKujskhZ+4XmbABPMSjt6L2PyMcovXW/59namRJsX5fS6z6kIj9H0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=huawei.com;\n spf=pass smtp.mailfrom=huawei.com;\n dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com\n header.b=3xqneVsJ; arc=none smtp.client-ip=113.46.200.216","dkim-signature":"v=1; a=rsa-sha256; d=huawei.com; s=dkim;\n\tc=relaxed/relaxed; q=dns/txt;\n\th=From;\n\tbh=8wsVxYBF+HbWZmM9SkeWkWH4YNIGWuIU3cJ+r0VuW+I=;\n\tb=3xqneVsJflRqVAbIiABUazmktjpEv1n12IxUL7ZKZfedAKRZcVlhArLwRS0J5gnDV0qXrRqa8\n\t2Ek/dtzZIsS8T7s8qwBPyPAJnlZomqgv5G30uux8IfC/hSbWzCqtFbbR52/eCY8mLp/Tc+62T6R\n\t9lDDfDnNH/KeuT7MigtrI8o=","Message-ID":"","Date":"Sat, 9 May 2026 11:28:03 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v8 4/7] vfio/pci: Add PCIe TPH interface with capability\n query","To":"Alex Williamson ","CC":", , ,\n\t, , ,\n\t, , ","References":"<20260508064053.37529-1-fengchengwen@huawei.com>\n <20260508064053.37529-5-fengchengwen@huawei.com>\n <20260508164003.70918c0c@shazbot.org>","Content-Language":"en-US","From":"fengchengwen ","In-Reply-To":"<20260508164003.70918c0c@shazbot.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"7bit","X-ClientProxiedBy":"kwepems100002.china.huawei.com (7.221.188.206) To\n kwepemk500009.china.huawei.com (7.202.194.94)"}}]