[{"id":3681516,"web_url":"http://patchwork.ozlabs.org/comment/3681516/","msgid":"<20260423145915.GG172828@unreal>","list_archive_url":null,"date":"2026-04-23T14:59:15","subject":"Re: [PATCH v3 0/5] vfio/pci: Add PCIe TPH support","submitter":{"id":68852,"url":"http://patchwork.ozlabs.org/api/people/68852/","name":"Leon Romanovsky","email":"leon@kernel.org"},"content":"On Thu, Apr 23, 2026 at 09:08:46AM +0800, Chengwen Feng wrote:\n> This series adds support for PCIe TLP Processing Hints (TPH) to\n> vfio-pci, allowing userspace to manage device steering tags for\n> improved performance and QoS in virtualized deployments.\n> \n> The implementation follows a clean incremental structure:\n> - Patch 1: Export pcie_tph_get_st_modes()\n> - Patch 2: Introduce UAPI ABI and implement capability query to\n>   let userspace discover supported TPH modes, ST table presence\n>   and size. Also add module parameter enable_unsafe_tph_ds to\n>   guard unsafe usage of TPH Device-Specific mode with no ST table.\n> - Patch 3: Add TPH enable/disable with mode selection. Restrict\n>   unsafe Device-Specific mode without ST table to be allowed only\n>   when the module parameter is enabled.\n> - Patch 4: Add interface to batch get per-CPU steering tags for\n>   device-specific mode without standard ST table. This interface\n>   is only available when the unsafe module parameter is enabled.\n> - Patch 5: Add interface to batch program steering tag table\n>   entries for standard TPH modes.\n> \n> All user API definitions are finalized in the first patch and\n> remain stable across the series. The design follows existing\n> VFIO conventions and relies on kernel pcie-tph infrastructure.\n> \n> To avoid potential security risks in virtualization environments,\n> TPH Device-Specific mode without a standard ST table is blocked\n> by default. It can only be enabled by administrators via the\n> enable_unsafe_tph_ds module parameter for trusted bare-metal\n> userspace.\n> \n> This series addresses the TPH management requirements discussed\n> in the RFC \"Proposal: Add sysfs interface for PCIe TPH Steering\n> Tag retrieval and configuration\".\n\nAs in the RFC, this patch series still lacks an explanation of *why* it is\nneeded. Please describe the scenario that cannot be handled without these\nchanges.\n\nThanks","headers":{"Return-Path":"\n <linux-pci+bounces-53048-incoming=patchwork.ozlabs.org@vger.kernel.org>","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=gnyWTlFd;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-53048-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=\"gnyWTlFd\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\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 4g1fPp2Qmwz1yD5\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 00:59:26 +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 932D73012E7E\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 23 Apr 2026 14:59:23 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A30E2221F20;\n\tThu, 23 Apr 2026 14:59:20 +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 806FE3246E8;\n\tThu, 23 Apr 2026 14:59:20 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id BD07AC2BCAF;\n\tThu, 23 Apr 2026 14:59:19 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776956360; cv=none;\n b=snd7LaLkpOwMO7ll3Ws8Ke5I7lljDzZf1L71e1n6R4g9NpZLlyoZT76vUFG8V9aIdsbOUONto+tmEqYyT14SVKwZu3Fnj2p6yOxiHh9hskfkXJE1lRWC3jhurlz+Sq/9qkTURy9wypetY1VcVGvSt4QNJi8jpfyfsJ3AzJqvotU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776956360; c=relaxed/simple;\n\tbh=n7r8iN3op2gCbPkpb8d9KEiHBDYYHBQtjCw6R8Tk/0g=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=YvdKNUdhas/4LaRXh76fv6ppjfq5gYm/ajmErhHwQG67l1ICu2iPz9Lh0G6fmXT0ducDCpoFiJuEZdYEEfxP1dNge4WEk1LbQ2m41Z+C8Kzoqx1HjI4lRfp7/W1IiQo4440hl6VF6z/cvXVkheaZSGfKZFTV58a991p3s9H7pco=","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=gnyWTlFd; 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=1776956360;\n\tbh=n7r8iN3op2gCbPkpb8d9KEiHBDYYHBQtjCw6R8Tk/0g=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=gnyWTlFdiiqbEUVkwoV3Ky5zmmhRoq6tENIeaFJBClu/hY8d3yAk4fRA5DeabAkun\n\t KfhhqVB3UAFR+HmakskFk0nL+Hk3xdNJCTL/dfwtVkeo07IYYq4wMwhll1rlpirP/6\n\t Z66fyABZX+9cdvOewr744zh5CiqzAi5uHenP3ddN+10DhgAMnnVQx5soaPCOVGw/4F\n\t KaGB5sEhW0sWyCo5yNog6pGHl+Ox6T8CYyXMfum/oy1WViZnaokEepbnOzQH4CEm/G\n\t mobJqStK+acZGvywnXkYKBbKA4ZGSJL0eLrbVq6xouk1UQyzlKaM5cXxhUJAe0xa3/\n\t 3bmqwuPdQNIKQ==","Date":"Thu, 23 Apr 2026 17:59:15 +0300","From":"Leon Romanovsky <leon@kernel.org>","To":"Chengwen Feng <fengchengwen@huawei.com>","Cc":"alex@shazbot.org, jgg@ziepe.ca, wathsala.vithanage@arm.com,\n\thelgaas@kernel.org, wangzhou1@hisilicon.com,\n\twangyushan12@huawei.com, liuyonglong@huawei.com,\n\tkvm@vger.kernel.org, linux-pci@vger.kernel.org","Subject":"Re: [PATCH v3 0/5] vfio/pci: Add PCIe TPH support","Message-ID":"<20260423145915.GG172828@unreal>","References":"<20260423010851.46737-1-fengchengwen@huawei.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260423010851.46737-1-fengchengwen@huawei.com>"}},{"id":3681722,"web_url":"http://patchwork.ozlabs.org/comment/3681722/","msgid":"<486a8633-437d-42d1-85f9-690a9df311eb@huawei.com>","list_archive_url":null,"date":"2026-04-24T01:25:54","subject":"Re: [PATCH v3 0/5] vfio/pci: Add PCIe TPH support","submitter":{"id":92756,"url":"http://patchwork.ozlabs.org/api/people/92756/","name":"fengchengwen","email":"fengchengwen@huawei.com"},"content":"On 4/23/2026 10:59 PM, Leon Romanovsky wrote:\n> On Thu, Apr 23, 2026 at 09:08:46AM +0800, Chengwen Feng wrote:\n>> This series adds support for PCIe TLP Processing Hints (TPH) to\n>> vfio-pci, allowing userspace to manage device steering tags for\n>> improved performance and QoS in virtualized deployments.\n>>\n>> The implementation follows a clean incremental structure:\n>> - Patch 1: Export pcie_tph_get_st_modes()\n>> - Patch 2: Introduce UAPI ABI and implement capability query to\n>>   let userspace discover supported TPH modes, ST table presence\n>>   and size. Also add module parameter enable_unsafe_tph_ds to\n>>   guard unsafe usage of TPH Device-Specific mode with no ST table.\n>> - Patch 3: Add TPH enable/disable with mode selection. Restrict\n>>   unsafe Device-Specific mode without ST table to be allowed only\n>>   when the module parameter is enabled.\n>> - Patch 4: Add interface to batch get per-CPU steering tags for\n>>   device-specific mode without standard ST table. This interface\n>>   is only available when the unsafe module parameter is enabled.\n>> - Patch 5: Add interface to batch program steering tag table\n>>   entries for standard TPH modes.\n>>\n>> All user API definitions are finalized in the first patch and\n>> remain stable across the series. The design follows existing\n>> VFIO conventions and relies on kernel pcie-tph infrastructure.\n>>\n>> To avoid potential security risks in virtualization environments,\n>> TPH Device-Specific mode without a standard ST table is blocked\n>> by default. It can only be enabled by administrators via the\n>> enable_unsafe_tph_ds module parameter for trusted bare-metal\n>> userspace.\n>>\n>> This series addresses the TPH management requirements discussed\n>> in the RFC \"Proposal: Add sysfs interface for PCIe TPH Steering\n>> Tag retrieval and configuration\".\n> \n> As in the RFC, this patch series still lacks an explanation of *why* it is\n> needed. Please describe the scenario that cannot be handled without these\n> changes.\n\nThanks for your review. To clarify the necessity in two clear layers:\n\n1. Why userspace needs the capability to control steering tags:\n   When PCIe devices are fully taken over by userspace workloads like DPDK\n   and SPDK, only userspace understands core binding policies and traffic\n   distribution. Without this series, userspace cannot enable TPH or\n   configure steering tags, leaving built-in PCIe performance optimizations\n   unused for high-throughput polling I/O scenarios.\n\n2. Why the interface must be implemented inside VFIO:\n   VFIO is the only mainstream and secure community solution for passing\n   complete PCIe device ownership to userspace. Existing kernel TPH\n   interfaces are designed exclusively for in-kernel drivers, so VFIO\n   provides the only correct, isolated path to expose per-device TPH\n   management for user-owned devices.\n\nThanks\n\n> \n> Thanks","headers":{"Return-Path":"\n <linux-pci+bounces-53086-incoming=patchwork.ozlabs.org@vger.kernel.org>","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=YbXIHNko;\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-53086-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=\"YbXIHNko\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=113.46.200.219","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 4g1wJy6KPKz1xvV\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 11:26:10 +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 27F5C300C026\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 01:26:07 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 99B5623645D;\n\tFri, 24 Apr 2026 01:26:06 +0000 (UTC)","from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com\n [113.46.200.219])\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 8A9D31A9F96;\n\tFri, 24 Apr 2026 01:26:04 +0000 (UTC)","from mail.maildlp.com (unknown [172.19.162.223])\n\tby canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4g1w9F3DSXz1prN9;\n\tFri, 24 Apr 2026 09:19:29 +0800 (CST)","from kwepemk500009.china.huawei.com (unknown [7.202.194.94])\n\tby mail.maildlp.com (Postfix) with ESMTPS id D863840571;\n\tFri, 24 Apr 2026 09:25:55 +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; Fri, 24 Apr 2026 09:25:55 +0800"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776993966; cv=none;\n b=sP5U4VhW8gZXeBMMC7qrwwTvFcx6UX2Xg1H5nB2WJfgTM/ESIr20WEU5h30b7Id2lEZvAiLYliidEdbwvu8fjYmo2fzdUi/NOmm6GJTJtIe4uzULou+w/M8VRquSK+nE7GVAT87b6bh8AeU6kVjMUg69U4NruM2pkGHMeiGqdd4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776993966; c=relaxed/simple;\n\tbh=i4s9DTXZuzdQZ28wjVuPTCFDMD2wsf4HN3JZjaN+vOg=;\n\th=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:\n\t In-Reply-To:Content-Type;\n b=Qb+UvWN0uH3+glxFhx8eeGF+ejuSsDD9WME6W5Qc5ocD+q8NgdWBGq/FRxfagqkOik7VDDhlmcKgj9XeaXEObg6Cv97Uoxe4TUurSCfOvdAAhPx6a1gkQA4WELC3e3dkQoNK8RKswx2BYJ5KXhsh0cqy2CvQNPmUHz5+DvfO0Y8=","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=YbXIHNko; arc=none smtp.client-ip=113.46.200.219","dkim-signature":"v=1; a=rsa-sha256; d=huawei.com; s=dkim;\n\tc=relaxed/relaxed; q=dns/txt;\n\th=From;\n\tbh=ZMhYimDVN3PWm9O6wHwuFObgia/AxLaO9IAmAW5Pbk4=;\n\tb=YbXIHNkoivr9IXDFkQgA3MJEcKS08F7teIcG0VKxfNt2fYhfwVrVIhWyeujsi4MJYHDTuSANp\n\tGQRI5jNRA13PDTpOzBKA83SqYNiRaWOs20NzqGU76hd+JR+gzmSk75bis7m8c3JUEo2rG6Sebf1\n\tv9cnfKUgo11fu3l/XIBGbRA=","Message-ID":"<486a8633-437d-42d1-85f9-690a9df311eb@huawei.com>","Date":"Fri, 24 Apr 2026 09:25:54 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v3 0/5] vfio/pci: Add PCIe TPH support","To":"Leon Romanovsky <leon@kernel.org>","CC":"<alex@shazbot.org>, <jgg@ziepe.ca>, <wathsala.vithanage@arm.com>,\n\t<helgaas@kernel.org>, <wangzhou1@hisilicon.com>, <wangyushan12@huawei.com>,\n\t<liuyonglong@huawei.com>, <kvm@vger.kernel.org>, <linux-pci@vger.kernel.org>","References":"<20260423010851.46737-1-fengchengwen@huawei.com>\n <20260423145915.GG172828@unreal>","Content-Language":"en-US","From":"fengchengwen <fengchengwen@huawei.com>","In-Reply-To":"<20260423145915.GG172828@unreal>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"7bit","X-ClientProxiedBy":"kwepems200001.china.huawei.com (7.221.188.67) To\n kwepemk500009.china.huawei.com (7.202.194.94)"}}]