[{"id":3677684,"web_url":"http://patchwork.ozlabs.org/comment/3677684/","msgid":"<518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>","list_archive_url":null,"date":"2026-04-15T13:55:37","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":90030,"url":"http://patchwork.ozlabs.org/api/people/90030/","name":"Wathsala Vithanage","email":"wathsala.vithanage@arm.com"},"content":"Hi Feng,\n\nget_st  feature is unsafe. It allows a rogue userspace driver in \ndevice-specific\nmode to obtain steering tags for arbitrary CPUs, including ones unrelated\nto the device or its workload, enabling it to direct traffic into those \nCPUs’\ncaches and potentially interfere with other workloads, opening doors to\nfurther exploits depending on other vulnerabilities.\n\nThat's why we dropped this capability in \nhttps://lore.kernel.org/kvm/20251013163515.16565-1-wathsala.vithanage@arm.com/\n\n--wathsala\n\n> }\n> \n> +static int vfio_pci_tph_get_st(struct vfio_pci_core_device *vdev,\n> +\t\t\t struct vfio_device_pci_tph_op *op,\n> +\t\t\t void __user *uarg)\n> +{\n> +\tstruct vfio_pci_tph_entry *ents;\n> +\tstruct vfio_pci_tph_st st;\n> +\tenum tph_mem_type mtype;\n> +\tsize_t size;\n> +\tint i, err;\n> +\n> +\tif (copy_from_user(&st, uarg, sizeof(st)))\n> +\t\treturn -EFAULT;\n> +\n> +\tif (!st.count || st.count > 2048)\n> +\t\treturn -EINVAL;\n> +\n> +\tsize = st.count * sizeof(*ents);\n> +\tents = kvmalloc(size, GFP_KERNEL);\n> +\tif (!ents)\n> +\t\treturn -ENOMEM;\n> +\n> +\tif (copy_from_user(ents, uarg + sizeof(st), size)) {\n> +\t\terr = -EFAULT;\n> +\t\tgoto out;\n> +\t}\n> +\n> +\tfor (i = 0; i < st.count; i++) {\n> +\t\tif (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_VM) {\n> +\t\t\tmtype = TPH_MEM_TYPE_VM;\n> +\t\t} else if (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_PM) {\n> +\t\t\tmtype = TPH_MEM_TYPE_PM;\n> +\t\t} else {\n> +\t\t\terr = -EINVAL;\n> +\t\t\tgoto out;\n> +\t\t}\n> +\n> +\t\terr = pcie_tph_get_cpu_st(vdev->pdev, mtype, ents[i].cpu, &ents[i].st);\n> +\t\tif (err)\n> +\t\t\tgoto out;\n> +\t}\n> +\n> +\tif (copy_to_user(uarg + sizeof(st), ents, size))\n> +\t\terr = -EFAULT;\n> +\n> +out:\n> +\tkvfree(ents);\n> +\treturn err;\n> +}\n> +\n> static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,\n> \t\t\t void __user *uarg)\n> {\n> @@ -1544,6 +1593,8 @@ static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,\n> \t\treturn vfio_pci_tph_enable(vdev, &op, uarg + minsz);\n> \tcase VFIO_PCI_TPH_DISABLE:\n> \t\treturn vfio_pci_tph_disable(vdev);\n> +\tcase VFIO_PCI_TPH_GET_ST:\n> +\t\treturn vfio_pci_tph_get_st(vdev, &op, uarg + minsz);\n> \tdefault:\n> \t\t/* Other ops are not implemented yet */\n> \t\treturn -EINVAL;","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=arm.com header.i=@arm.com header.a=rsa-sha256\n header.s=foss header.b=k+X5mnHm;\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-52555-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com\n header.b=\"k+X5mnHm\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=217.140.110.172","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=arm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=arm.com"],"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 4fwjN418q6z1yHM\n\tfor ; Wed, 15 Apr 2026 23:55:48 +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 8484B3009084\n\tfor ; Wed, 15 Apr 2026 13:55:43 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 004BF3CF68B;\n\tWed, 15 Apr 2026 13:55:42 +0000 (UTC)","from foss.arm.com (foss.arm.com [217.140.110.172])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CF8863CF031;\n\tWed, 15 Apr 2026 13:55:38 +0000 (UTC)","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4F8A24FAA;\n\tWed, 15 Apr 2026 06:55:32 -0700 (PDT)","from [10.122.46.229] (unknown [10.122.46.229])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B04E13F7B4;\n\tWed, 15 Apr 2026 06:55:37 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776261341; cv=none;\n b=fbo6rYQI3xY0+i3+NTgELxKey35x5REubl6rWEPoUSgUKeXqA+v7lqg3+CapW686nJmC9oFfOYBFv6OZSZKpoT1Ca8l7mIfAm0JEKzKP3GSTV3EABn+N45kqAWN0/KwcsdRTfN2EzyHuHbjq5YHKExbZFd5JmQUmwKMx+aO10Qs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776261341; c=relaxed/simple;\n\tbh=afT+/AJfr9Pd0za1i+sG5FU8fIdRySrPPxD6GeF5phE=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=Sq14KMISEPvpDpgFPwp/9HbTiOzzMQkBtecoRQjS9TmaDo00ZDDfmPNZrwE+tIN7MUwEh5xclQM8Jc43ADY3MX7gTiSEtKeC6x9syNLhXbFRP3NZg/y++afuX7zlJCBQf9AExcFg0HRByUF4nmCDvaX2FlD1k4Msd6iufybxJEc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=arm.com;\n spf=pass smtp.mailfrom=arm.com;\n dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com\n header.b=k+X5mnHm; arc=none smtp.client-ip=217.140.110.172","DKIM-Signature":"v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;\n\tt=1776261337; bh=afT+/AJfr9Pd0za1i+sG5FU8fIdRySrPPxD6GeF5phE=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=k+X5mnHm7hL+pj79CT721bT30dLBzwUTIuoMj8u2JJZ8J+Ijnpx99cGgiheJqXXZj\n\t KOmB7JtgJz6zyo9B0V8NlpJFgb7D2AjkyUdKLxZuTkHn0pmfkR2ouPjnvvkTY9ugHU\n\t YUhZLAvod9LMwm0jz0Bwm90fRZjGt1l2SPVv5E/E=","Message-ID":"<518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>","Date":"Wed, 15 Apr 2026 08:55:37 -0500","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 3/4] vfio/pci: Add PCIe TPH GET_ST interface","To":"Chengwen Feng , alex@shazbot.org, jgg@ziepe.ca","Cc":"kvm@vger.kernel.org, linux-pci@vger.kernel.org","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n <20260415090959.53672-4-fengchengwen@huawei.com>","Content-Language":"en-US","From":"Wathsala Vithanage ","In-Reply-To":"<20260415090959.53672-4-fengchengwen@huawei.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":3677885,"web_url":"http://patchwork.ozlabs.org/comment/3677885/","msgid":"<41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>","list_archive_url":null,"date":"2026-04-16T01:09:50","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":92756,"url":"http://patchwork.ozlabs.org/api/people/92756/","name":"fengchengwen","email":"fengchengwen@huawei.com"},"content":"On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:\n> Hi Feng,\n> \n> get_st  feature is unsafe. It allows a rogue userspace driver in device-specific\n> mode to obtain steering tags for arbitrary CPUs, including ones unrelated\n> to the device or its workload, enabling it to direct traffic into those CPUs’\n> caches and potentially interfere with other workloads, opening doors to\n> further exploits depending on other vulnerabilities.\n\nThank you for the follow-up and for referencing the prior RFC\ndiscussion on this topic. I appreciate you clarifying the\nhistorical context of the safety concerns.\n\nI acknowledge the risks you’ve highlighted, but I believe the\nrisk profile in this VFIO interface is different and already\nwell bounded by existing design and practice:\n\n1. VFIO device access requires elevated privileges\n A userspace process can only open a VFIO device node if it\n has sufficient privileges (typically root). This is not an\n interface for unprivileged users.\n\n2. In the thread \"[RFC v2 0/2] Retrieve tph from dmabuf for PCIe\n P2P memory access\", applications can configure the steertag\n of exported dmabufs from userspace to the kernel. Kernel PCIe\n drivers (e.g., mlx5 NIC) then use these steertags and set them\n to their ST tables. Even here, userspace could set invalid\n steertags that impact GPU performance—but this model is\n basically accepted I think (refer from maillist discuss).\n\n3. Malicious resource consumption is not unique to TPH\n A malicious thread can be created to forcibly consume CPU\n resources and bound to a specific CPU, affecting other CPUs.\n This is a general system security concern, not one specific\n to TPH GET_ST, and is addressed by existing system hardening\n and access control mechanisms—not by removing useful features.\n\n4. GET_ST is strictly necessary for Device-Specific (DS) mode\n when no ST table is present on the device.\n For devices that do not have a dedicated ST table (a common\n scenario in many PCIe endpoints), DS mode requires userspace\n to retrieve per-CPU steering tags first, then program them\n into the device’s steering logic via other registers. Without\n GET_ST, userspace cannot obtain the required steertags to\n enable TPH DS mode at all—rendering TPH support useless for\n these devices. This is not an optional feature but a\n fundamental requirement to unlock TPH functionality for a\n large class of hardware.\n\nGiven these points—privilege restriction, existing industry\npractice, general system security mitigations, and strict\nfunctional necessity for DS mode—I believe GET_ST is reasonable\nand consistent with existing VFIO security boundaries.\n\nThanks\n\n> \n> That's why we dropped this capability in https://lore.kernel.org/kvm/20251013163515.16565-1-wathsala.vithanage@arm.com/\n> \n> --wathsala\n> \n>>   }\n>>   +static int vfio_pci_tph_get_st(struct vfio_pci_core_device *vdev,\n>> +                   struct vfio_device_pci_tph_op *op,\n>> +                   void __user *uarg)\n>> +{\n>> +    struct vfio_pci_tph_entry *ents;\n>> +    struct vfio_pci_tph_st st;\n>> +    enum tph_mem_type mtype;\n>> +    size_t size;\n>> +    int i, err;\n>> +\n>> +    if (copy_from_user(&st, uarg, sizeof(st)))\n>> +        return -EFAULT;\n>> +\n>> +    if (!st.count || st.count > 2048)\n>> +        return -EINVAL;\n>> +\n>> +    size = st.count * sizeof(*ents);\n>> +    ents = kvmalloc(size, GFP_KERNEL);\n>> +    if (!ents)\n>> +        return -ENOMEM;\n>> +\n>> +    if (copy_from_user(ents, uarg + sizeof(st), size)) {\n>> +        err = -EFAULT;\n>> +        goto out;\n>> +    }\n>> +\n>> +    for (i = 0; i < st.count; i++) {\n>> +        if (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_VM) {\n>> +            mtype = TPH_MEM_TYPE_VM;\n>> +        } else if (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_PM) {\n>> +            mtype = TPH_MEM_TYPE_PM;\n>> +        } else {\n>> +            err = -EINVAL;\n>> +            goto out;\n>> +        }\n>> +\n>> +        err = pcie_tph_get_cpu_st(vdev->pdev, mtype, ents[i].cpu, &ents[i].st);\n>> +        if (err)\n>> +            goto out;\n>> +    }\n>> +\n>> +    if (copy_to_user(uarg + sizeof(st), ents, size))\n>> +        err = -EFAULT;\n>> +\n>> +out:\n>> +    kvfree(ents);\n>> +    return err;\n>> +}\n>> +\n>>   static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,\n>>                     void __user *uarg)\n>>   {\n>> @@ -1544,6 +1593,8 @@ static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,\n>>           return vfio_pci_tph_enable(vdev, &op, uarg + minsz);\n>>       case VFIO_PCI_TPH_DISABLE:\n>>           return vfio_pci_tph_disable(vdev);\n>> +    case VFIO_PCI_TPH_GET_ST:\n>> +        return vfio_pci_tph_get_st(vdev, &op, uarg + minsz);\n>>       default:\n>>           /* Other ops are not implemented yet */\n>>           return -EINVAL;\n>","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=Vm4pJhQJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52567-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=\"Vm4pJhQJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=113.46.200.222","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 [172.234.253.10])\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 4fx0Nt3yvmz1yCv\n\tfor ; Thu, 16 Apr 2026 11:12:30 +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 4E29B301C59A\n\tfor ; Thu, 16 Apr 2026 01:09:59 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id AC93B175A85;\n\tThu, 16 Apr 2026 01:09:58 +0000 (UTC)","from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com\n [113.46.200.222])\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 53ECB26AF4;\n\tThu, 16 Apr 2026 01:09:55 +0000 (UTC)","from mail.maildlp.com (unknown [172.19.163.163])\n\tby canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4fx0BY42S6zLlYJ;\n\tThu, 16 Apr 2026 09:03:33 +0800 (CST)","from kwepemk500009.china.huawei.com (unknown [7.202.194.94])\n\tby mail.maildlp.com (Postfix) with ESMTPS id 85C304048B;\n\tThu, 16 Apr 2026 09:09:51 +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; Thu, 16 Apr 2026 09:09:51 +0800"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776301798; cv=none;\n b=awbI7g3/qheEavxtFGJ0mMsQAhAyXe7b4MAY5ovEBV/SoCOa9oozsfPTGaVbhUK5i22QVzJzxGBcRLk3RMC30Z4S/T4XvaxGoDrY/xW91GuOHCnyJiOdWFGPK1RBcXe6X1reUQaT2wSBikEJ9e1CXVU1VrG9V6v0gJDorDT3zOU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776301798; c=relaxed/simple;\n\tbh=E7SGXbGxKh0ZpZ9Qh9s4jm02yr8nkNGxmiq15Mo7dbo=;\n\th=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:\n\t In-Reply-To:Content-Type;\n b=BEpbiZWqW/GQegRA12iXl5yPa2H2r7o2N3uIQGnOgoMT2W1PQji1tNLrzdfpZPthJ/l6hUaUQn4XioFw4zUgwn+cYWFPoVUIVyUMZo7PjYXnSOdTMUQkKNXkatm2UUidxpFyN42Lv9JSOeiX/9bc8g0CYDZkCBlZwphBNFEqcAw=","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=Vm4pJhQJ; arc=none smtp.client-ip=113.46.200.222","dkim-signature":"v=1; a=rsa-sha256; d=huawei.com; s=dkim;\n\tc=relaxed/relaxed; q=dns/txt;\n\th=From;\n\tbh=NHDiCQ6LLDvqkjDtqZT0emfpZJwHIt5pQk1ry5pNd4E=;\n\tb=Vm4pJhQJDbt3F73dV/rXoWeDqwxdklnL882vUOBfjJOB0j23k1wNwMf1+gq2KxYlVOPX8dmFV\n\tFL43fOaFYGOqv+jOFEDpSknn1AKr/65t5fCaRs0szOBBaWWsS4yE7r+8EiwRPaQpa0WxnSAkNcV\n\tOkS+n+oB9KFiBqQ83SkzRkQ=","Message-ID":"<41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>","Date":"Thu, 16 Apr 2026 09:09:50 +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 3/4] vfio/pci: Add PCIe TPH GET_ST interface","To":"Wathsala Vithanage , ,\n\t","CC":", ","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n <20260415090959.53672-4-fengchengwen@huawei.com>\n <518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>","Content-Language":"en-US","From":"fengchengwen ","In-Reply-To":"<518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"kwepems200001.china.huawei.com (7.221.188.67) To\n kwepemk500009.china.huawei.com (7.202.194.94)"}},{"id":3678179,"web_url":"http://patchwork.ozlabs.org/comment/3678179/","msgid":"<20260416074020.57e4ed72@shazbot.org>","list_archive_url":null,"date":"2026-04-16T13:40:20","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":91887,"url":"http://patchwork.ozlabs.org/api/people/91887/","name":"Alex Williamson","email":"alex@shazbot.org"},"content":"On Thu, 16 Apr 2026 09:09:50 +0800\nfengchengwen wrote:\n\n> On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:\n> > Hi Feng,\n> > \n> > get_st  feature is unsafe. It allows a rogue userspace driver in device-specific\n> > mode to obtain steering tags for arbitrary CPUs, including ones unrelated\n> > to the device or its workload, enabling it to direct traffic into those CPUs’\n> > caches and potentially interfere with other workloads, opening doors to\n> > further exploits depending on other vulnerabilities. \n> \n> Thank you for the follow-up and for referencing the prior RFC\n> discussion on this topic. I appreciate you clarifying the\n> historical context of the safety concerns.\n> \n> I acknowledge the risks you’ve highlighted, but I believe the\n> risk profile in this VFIO interface is different and already\n> well bounded by existing design and practice:\n> \n> 1. VFIO device access requires elevated privileges\n> A userspace process can only open a VFIO device node if it\n> has sufficient privileges (typically root). This is not an\n> interface for unprivileged users.\n\nThis argument is NOT helping your cause. This is not the usage model\nwe design for. VFIO usage requires that privileges be granted to a\nuser, in the form of device ACL access and locked memory, but does not\ngenerally require elevated privileges beyond that, or otherwise grant\nthe user authority beyond the scope of the device. The root use case\nmay be typical for you, but is not required for many other typical use\ncases, such as device assignment to VMs.\n \n> 2. In the thread \"[RFC v2 0/2] Retrieve tph from dmabuf for PCIe\n> P2P memory access\", applications can configure the steertag\n> of exported dmabufs from userspace to the kernel. Kernel PCIe\n> drivers (e.g., mlx5 NIC) then use these steertags and set them\n> to their ST tables. Even here, userspace could set invalid\n> steertags that impact GPU performance—but this model is\n> basically accepted I think (refer from maillist discuss).\n\nIt's an RFC. It's bold to claim that it's nearly accepted.\n\n> 3. Malicious resource consumption is not unique to TPH\n> A malicious thread can be created to forcibly consume CPU\n> resources and bound to a specific CPU, affecting other CPUs.\n> This is a general system security concern, not one specific\n> to TPH GET_ST, and is addressed by existing system hardening\n> and access control mechanisms—not by removing useful features.\n\nYou're conflating process abuse of a CPU to a potential side-channel\nDMA attach from a device. What *existing* hardening protects against\nthe latter?\n\n> 4. GET_ST is strictly necessary for Device-Specific (DS) mode\n> when no ST table is present on the device.\n> For devices that do not have a dedicated ST table (a common\n> scenario in many PCIe endpoints), DS mode requires userspace\n> to retrieve per-CPU steering tags first, then program them\n> into the device’s steering logic via other registers. Without\n> GET_ST, userspace cannot obtain the required steertags to\n> enable TPH DS mode at all—rendering TPH support useless for\n> these devices. This is not an optional feature but a\n> fundamental requirement to unlock TPH functionality for a\n> large class of hardware.\n\nUnlocking a hardware feature does not give you authority to ignore the\nsecurity implications of that feature. 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=fm1 header.b=cL02z3/J;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=BS60DdTJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52617-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=\"cL02z3/J\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"BS60DdTJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.12.124.144","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 sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::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 4fxK1Y4mv9z1yHP\n\tfor ; Thu, 16 Apr 2026 23:41:53 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 3E9AC301C3F2\n\tfor ; Thu, 16 Apr 2026 13:40:29 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 0DC4826560B;\n\tThu, 16 Apr 2026 13:40:28 +0000 (UTC)","from fout-b1-smtp.messagingengine.com\n (fout-b1-smtp.messagingengine.com [202.12.124.144])\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 413F23A1E95;\n\tThu, 16 Apr 2026 13:40:24 +0000 (UTC)","from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])\n\tby mailfout.stl.internal (Postfix) with ESMTP id A9CBB1D002E6;\n\tThu, 16 Apr 2026 09:40:23 -0400 (EDT)","from phl-frontend-04 ([10.202.2.163])\n by phl-compute-03.internal (MEProxy); Thu, 16 Apr 2026 09:40:24 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Thu,\n 16 Apr 2026 09:40:21 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776346827; cv=none;\n b=mcCvjKh0i5QC6IoutAejGyvwFQe6niczx333hQIaZBHT36zYCLYpprS9gNgxa/3FkqYU62n0quIRHhe4aRU5FuJdfjqxBaJhnla9xInm9RkgAIN0D977tEkKBT0xFG3w1REYYIeox4aWnm+VpoNhxBxMqSKaud+r49l68ZkF/LU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776346827; c=relaxed/simple;\n\tbh=+Cm8zdxXLz7bcaZJWZhDWcXgaMPEgeSJ2u2pQZs12FE=;\n\th=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:\n\t MIME-Version:Content-Type;\n b=nlKE62vwk3m7o9DtcXFk0jbq84Ie0zvMeuXaJ9JUutEyBPMarTXpaNePvrU69T1FjEVORgljzi79h/4vv86UlVWRmwQBg1pEe9/AEPJBNQiqo232q7tPCEXhbHyGVJj8WlFw+eVVeNmJIGDa4tmxLrdeuIx2sgN39yKEcMCiOrU=","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=cL02z3/J;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=BS60DdTJ; arc=none smtp.client-ip=202.12.124.144","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=fm1; t=1776346823;\n\t x=1776433223; bh=/wRBy3MPr3uBglPzHimTBE2v1WQkXuAVNb1SXsJzKsM=; b=\n\tcL02z3/JXlwXMIQ0hL1iyF5rr0TSqB5ClZHgEvF5j+Gs+IPXwYKrIrti5g3qNB6w\n\tK4JpGKiFJVUVS0yIkGmQINGU1W9PKii0POKonkmSQN5oRBFwbiU+iGo9cOBamNCN\n\tO/ZyNDVXBu+QwN1/vyjNYG4Yc9HTsMI9tmof7R/cYU6JcqRNzpTRD1RTqqoZWxvv\n\tmpe7vXSLXW7OVgL5ruuw/I04jwR5I/l50iWF1sfDHKRhBJCBvuphpZuLblrarjEt\n\tz/3v2FtE/T6nA4TCmuMgQPC4x9Z57uvmJgIR2fyZmRFijg2MCNwjcNElqH61sFE4\n\trr+oxz7sKEkRaYzjYw+8Ow==","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=fm2; t=1776346823; x=\n\t1776433223; bh=/wRBy3MPr3uBglPzHimTBE2v1WQkXuAVNb1SXsJzKsM=; b=B\n\tS60DdTJFyzVflIZg8wsFxtK3sjKlEmry5YC5XeT2NNnwz/gSdBe6c5z/V+7kZmdd\n\tfG2BoNE1fb2STkQEspaL66lUFrDx5qxd888i5edZdO+YSwFgYWhsNMc4JtFoEFXZ\n\tosOhP0SpQgQxNPTe8LQaphMvsW4O6UFEhYPEBVgC3EAKLiprGbUtjHGkuOCSTqF2\n\tqfxtaINc4dIInHOhKF8eUHMU1FWT+uP1muOFRigkWOPKNBsqw6GVA7XOLBAxjqGB\n\tviGWVSltZZsUqrk65F8vvqX5z6e0rH5mhMnVN20dbesrqHZ1FQW6oK3ESh3lp0J9\n\tRQ1HqdfPNkqfi++1BLf9A=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdegjedugecutefuodetggdotefrod\n ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug\n hrpeffhffvvefukfgjfhfogggtgfesthhqredtredtjeenucfhrhhomheptehlvgigucgh\n ihhllhhirghmshhonhcuoegrlhgvgiesshhhrgiisghothdrohhrgheqnecuggftrfgrth\n htvghrnhepgeduvefhjeeufeevudeiueeuieeftedtkeevkefhgfdvteefleeuhefgtdeh\n fffhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg\n hlvgigsehshhgriigsohhtrdhorhhgpdhnsggprhgtphhtthhopeeipdhmohguvgepshhm\n thhpohhuthdprhgtphhtthhopehfvghnghgthhgvnhhgfigvnheshhhurgifvghirdgtoh\n hmpdhrtghpthhtohepfigrthhhshgrlhgrrdhvihhthhgrnhgrghgvsegrrhhmrdgtohhm\n pdhrtghpthhtohepjhhgghesiihivghpvgdrtggrpdhrtghpthhtohepkhhvmhesvhhgvg\n hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhptghisehvghgvrhdr\n khgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghlvgigsehshhgriigsohhtrdhorhhg","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"i03f14258:Fastmail","Date":"Thu, 16 Apr 2026 07:40:20 -0600","From":"Alex Williamson ","To":"fengchengwen ","Cc":"Wathsala Vithanage , ,\n , , alex@shazbot.org","Subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","Message-ID":"<20260416074020.57e4ed72@shazbot.org>","In-Reply-To":"<41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n\t<20260415090959.53672-4-fengchengwen@huawei.com>\n\t<518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>\n\t<41d5b3ea-abe2-4583-be88-2addf6b4d394@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=UTF-8","Content-Transfer-Encoding":"quoted-printable"}},{"id":3678273,"web_url":"http://patchwork.ozlabs.org/comment/3678273/","msgid":"<0b19a6ce-f328-4b63-a2c4-e9ee43ee7e92@arm.com>","list_archive_url":null,"date":"2026-04-16T16:12:57","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":90030,"url":"http://patchwork.ozlabs.org/api/people/90030/","name":"Wathsala Vithanage","email":"wathsala.vithanage@arm.com"},"content":"On 4/16/26 08:40, Alex Williamson wrote:\n> On Thu, 16 Apr 2026 09:09:50 +0800\n> fengchengwen wrote:\n>\n>> On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:\n>>> Hi Feng,\n>>>\n>>> get_st  feature is unsafe. It allows a rogue userspace driver in device-specific\n>>> mode to obtain steering tags for arbitrary CPUs, including ones unrelated\n>>> to the device or its workload, enabling it to direct traffic into those CPUs’\n>>> caches and potentially interfere with other workloads, opening doors to\n>>> further exploits depending on other vulnerabilities.\n>> Thank you for the follow-up and for referencing the prior RFC\n>> discussion on this topic. I appreciate you clarifying the\n>> historical context of the safety concerns.\n>>\n>> I acknowledge the risks you’ve highlighted, but I believe the\n>> risk profile in this VFIO interface is different and already\n>> well bounded by existing design and practice:\n>>\n>> 1. VFIO device access requires elevated privileges\n>> A userspace process can only open a VFIO device node if it\n>> has sufficient privileges (typically root). This is not an\n>> interface for unprivileged users.\n> This argument is NOT helping your cause. This is not the usage model\n> we design for. VFIO usage requires that privileges be granted to a\n> user, in the form of device ACL access and locked memory, but does not\n> generally require elevated privileges beyond that, or otherwise grant\n> the user authority beyond the scope of the device. The root use case\n> may be typical for you, but is not required for many other typical use\n> cases, such as device assignment to VMs.\n> \n>> 2. In the thread \"[RFC v2 0/2] Retrieve tph from dmabuf for PCIe\n>> P2P memory access\", applications can configure the steertag\n>> of exported dmabufs from userspace to the kernel. Kernel PCIe\n>> drivers (e.g., mlx5 NIC) then use these steertags and set them\n>> to their ST tables. Even here, userspace could set invalid\n>> steertags that impact GPU performance—but this model is\n>> basically accepted I think (refer from maillist discuss).\n> It's an RFC. It's bold to claim that it's nearly accepted.\n>\n>> 3. Malicious resource consumption is not unique to TPH\n>> A malicious thread can be created to forcibly consume CPU\n>> resources and bound to a specific CPU, affecting other CPUs.\n>> This is a general system security concern, not one specific\n>> to TPH GET_ST, and is addressed by existing system hardening\n>> and access control mechanisms—not by removing useful features.\n> You're conflating process abuse of a CPU to a potential side-channel\n> DMA attach from a device. What *existing* hardening protects against\n> the latter?\n>\n>> 4. GET_ST is strictly necessary for Device-Specific (DS) mode\n>> when no ST table is present on the device.\n>> For devices that do not have a dedicated ST table (a common\n>> scenario in many PCIe endpoints), DS mode requires userspace\n>> to retrieve per-CPU steering tags first, then program them\n>> into the device’s steering logic via other registers. Without\n>> GET_ST, userspace cannot obtain the required steertags to\n>> enable TPH DS mode at all—rendering TPH support useless for\n>> these devices. This is not an optional feature but a\n>> fundamental requirement to unlock TPH functionality for a\n>> large class of hardware.\n> Unlocking a hardware feature does not give you authority to ignore the\n> security implications of that feature. Thanks,\n>\n> Alex\n\n\nFirst vfio-TPH RFC captures some of the risks\nhttps://lore.kernel.org/kvm/20250221224638.1836909-1-wathsala.vithanage@arm.com/\n\n--wathsala","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=arm.com header.i=@arm.com header.a=rsa-sha256\n header.s=foss header.b=iLOIt90s;\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-52621-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com\n header.b=\"iLOIt90s\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=217.140.110.172","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=arm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=arm.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 4fxNNC0qyFz1yHP\n\tfor ; Fri, 17 Apr 2026 02:13:15 +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 C37A7302C17D\n\tfor ; Thu, 16 Apr 2026 16:13:12 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 03E4C12D21B;\n\tThu, 16 Apr 2026 16:13:12 +0000 (UTC)","from foss.arm.com (foss.arm.com [217.140.110.172])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5891C3B1B3;\n\tThu, 16 Apr 2026 16:13:09 +0000 (UTC)","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 092AD2574;\n\tThu, 16 Apr 2026 09:13:03 -0700 (PDT)","from [192.168.86.29] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4B6723F7D8;\n\tThu, 16 Apr 2026 09:13:08 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776355991; cv=none;\n b=D2Yz8iQvCptpR/JsUiWx9MB7ZpXID43KLAvCE6U071zLV1LYVxj/pKXZ1/7e1dW/CIY9ugyP/pYuktLM2VRwU/pJY0N08gm4pSNUegYquPfWb/Ne6XCdxA+CQLviwGw+rUSchpJB9cHwdKvUtEIqTVxAd7ngunbbBDqRZcHrx6I=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776355991; c=relaxed/simple;\n\tbh=9tR51p0l4s/flblZnKk0MR9Vl7hTT1JTEbq0OQtufA0=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=mdywW4VKJreY8MhYthmU6vU15zZ7iUYfB1R45NYi1tFkXEQQylipjEU9JL8EUxootI7sJtBrHl8iXtgxbWiKrX5ZBQ66OksJFb2CzYnew5Ekn/sCAUKWolbBTRqJd9DqaOcZU1sIbZ+r4o/XBnjvSdFoXbGhQwjD95ZUu4OkKTo=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=arm.com;\n spf=pass smtp.mailfrom=arm.com;\n dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com\n header.b=iLOIt90s; arc=none smtp.client-ip=217.140.110.172","DKIM-Signature":"v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;\n\tt=1776355988; bh=9tR51p0l4s/flblZnKk0MR9Vl7hTT1JTEbq0OQtufA0=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=iLOIt90slMti4C7NoBX3mXZi90CcmQkEFt0spI1yYWzLFepipmwED6ZkgWRLF3LvG\n\t P9OTrAeeVCW8i9piORhJ6FwrqCV702UKcvfYslVCaq+RRoGFblGqCgphLz8vIfzBB2\n\t vn+J6Qv44oYBUIjfW+E1bt0rD2G0vWUsbtuCUpwk=","Message-ID":"<0b19a6ce-f328-4b63-a2c4-e9ee43ee7e92@arm.com>","Date":"Thu, 16 Apr 2026 11:12:57 -0500","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 3/4] vfio/pci: Add PCIe TPH GET_ST interface","To":"Alex Williamson , fengchengwen ","Cc":"jgg@ziepe.ca, kvm@vger.kernel.org, linux-pci@vger.kernel.org","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n <20260415090959.53672-4-fengchengwen@huawei.com>\n <518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>\n <41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>\n <20260416074020.57e4ed72@shazbot.org>","Content-Language":"en-US","From":"Wathsala Vithanage ","In-Reply-To":"<20260416074020.57e4ed72@shazbot.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":3678444,"web_url":"http://patchwork.ozlabs.org/comment/3678444/","msgid":"<5ed17a05-1dee-49c2-8d40-a1db8f67ef13@huawei.com>","list_archive_url":null,"date":"2026-04-17T00:48:31","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":92756,"url":"http://patchwork.ozlabs.org/api/people/92756/","name":"fengchengwen","email":"fengchengwen@huawei.com"},"content":"Hi Alex,\n\nThank you very much for your clear and detailed security explanation.\nI fully understand and agree with your security concerns about allowing\nuserspace to query steering tags for arbitrary CPUs.\n\nTo completely resolve this security issue while retaining the mandatory\nfunctionality for DS-mode devices without ST table, I will revise the\nGET_ST interface with a strict security constraint in v3:\n\n The CPU number provided by userspace will be VALIDATED TO EQUAL\n THE CURRENT CALLING CPU of the ioctl().\n\nIn other words:\n- Userspace can ONLY query the steering tag for the CPU it is currently\n running on.\n- Userspace CANNOT query any other CPU.\n- No cross-CPU probing, no side-channel, no attack surface.\n- No ability to influence or target other CPUs.\n\nThis completely eliminates the security exposure you mentioned, while\nstill fully supporting the Device-Specific mode requirement for devices\nwithout ST tables.\n\nThanks\n\nOn 4/16/2026 9:40 PM, Alex Williamson wrote:\n> On Thu, 16 Apr 2026 09:09:50 +0800\n> fengchengwen wrote:\n> \n>> On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:\n>>> Hi Feng,\n>>>\n>>> get_st  feature is unsafe. It allows a rogue userspace driver in device-specific\n>>> mode to obtain steering tags for arbitrary CPUs, including ones unrelated\n>>> to the device or its workload, enabling it to direct traffic into those CPUs’\n>>> caches and potentially interfere with other workloads, opening doors to\n>>> further exploits depending on other vulnerabilities. \n>>\n>> Thank you for the follow-up and for referencing the prior RFC\n>> discussion on this topic. I appreciate you clarifying the\n>> historical context of the safety concerns.\n>>\n>> I acknowledge the risks you’ve highlighted, but I believe the\n>> risk profile in this VFIO interface is different and already\n>> well bounded by existing design and practice:\n>>\n>> 1. VFIO device access requires elevated privileges\n>> A userspace process can only open a VFIO device node if it\n>> has sufficient privileges (typically root). This is not an\n>> interface for unprivileged users.\n> \n> This argument is NOT helping your cause. This is not the usage model\n> we design for. VFIO usage requires that privileges be granted to a\n> user, in the form of device ACL access and locked memory, but does not\n> generally require elevated privileges beyond that, or otherwise grant\n> the user authority beyond the scope of the device. The root use case\n> may be typical for you, but is not required for many other typical use\n> cases, such as device assignment to VMs.\n> \n>> 2. In the thread \"[RFC v2 0/2] Retrieve tph from dmabuf for PCIe\n>> P2P memory access\", applications can configure the steertag\n>> of exported dmabufs from userspace to the kernel. Kernel PCIe\n>> drivers (e.g., mlx5 NIC) then use these steertags and set them\n>> to their ST tables. Even here, userspace could set invalid\n>> steertags that impact GPU performance—but this model is\n>> basically accepted I think (refer from maillist discuss).\n> \n> It's an RFC. It's bold to claim that it's nearly accepted.\n> \n>> 3. Malicious resource consumption is not unique to TPH\n>> A malicious thread can be created to forcibly consume CPU\n>> resources and bound to a specific CPU, affecting other CPUs.\n>> This is a general system security concern, not one specific\n>> to TPH GET_ST, and is addressed by existing system hardening\n>> and access control mechanisms—not by removing useful features.\n> \n> You're conflating process abuse of a CPU to a potential side-channel\n> DMA attach from a device. What *existing* hardening protects against\n> the latter?\n> \n>> 4. GET_ST is strictly necessary for Device-Specific (DS) mode\n>> when no ST table is present on the device.\n>> For devices that do not have a dedicated ST table (a common\n>> scenario in many PCIe endpoints), DS mode requires userspace\n>> to retrieve per-CPU steering tags first, then program them\n>> into the device’s steering logic via other registers. Without\n>> GET_ST, userspace cannot obtain the required steertags to\n>> enable TPH DS mode at all—rendering TPH support useless for\n>> these devices. This is not an optional feature but a\n>> fundamental requirement to unlock TPH functionality for a\n>> large class of hardware.\n> \n> Unlocking a hardware feature does not give you authority to ignore the\n> security implications of that feature. 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=Y+rc53sI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52672-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=\"Y+rc53sI\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=113.46.200.220","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 sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::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 4fxbq2566yz1yD3\n\tfor ; Fri, 17 Apr 2026 10:48:46 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 76C833016D25\n\tfor ; Fri, 17 Apr 2026 00:48:40 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A316372622;\n\tFri, 17 Apr 2026 00:48:38 +0000 (UTC)","from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com\n [113.46.200.220])\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 54E941F7916;\n\tFri, 17 Apr 2026 00:48:35 +0000 (UTC)","from mail.maildlp.com (unknown [172.19.162.223])\n\tby canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4fxbgW4xnjz12LDP;\n\tFri, 17 Apr 2026 08:42:15 +0800 (CST)","from kwepemk500009.china.huawei.com (unknown [7.202.194.94])\n\tby mail.maildlp.com (Postfix) with ESMTPS id B149540561;\n\tFri, 17 Apr 2026 08:48:32 +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, 17 Apr 2026 08:48:32 +0800"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776386918; cv=none;\n b=iyHEG+NOj4pT0T3SDOO5gYy5ZQTov+oalPVlVaHxAMogLZRV1Mt7hfx0MZ0vKdR7WFU2T0pDk6h3abq1Pyhaj5zdauViOAPb5URNHuVshEsJpobC5m5eRxSWRoG3rXKsoGi0YRJxKe93PASTnAQ2WjMaDUNVCa5HSebYyIDieQo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776386918; c=relaxed/simple;\n\tbh=oLFcl88eWXQXucj6DoxcVHUiprn6Aw1tvz6UrxSUJLc=;\n\th=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:\n\t In-Reply-To:Content-Type;\n b=jmsdNx+ihVHapBVXoStEzCrzNdmyqOCjIY+i/J5zg4fmzC6K3GugJsYHlKJOlbJ3hKBHWcUnaHtuRJTjxKfgbdQCBm5luNl3+Ipkq/+jUa0mL4Cy4dJT/qSp8+OR5tLjJ++ofVM1Tp5FtMCg2swr6Q/+gLxlU3jUMubPghgEdUM=","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=Y+rc53sI; arc=none smtp.client-ip=113.46.200.220","dkim-signature":"v=1; a=rsa-sha256; d=huawei.com; s=dkim;\n\tc=relaxed/relaxed; q=dns/txt;\n\th=From;\n\tbh=Z6h+QXuK/S/F4/p4HaQdGt2hHxkqesC4Tpd9pXe/VvY=;\n\tb=Y+rc53sIM6B8UAazz9eEM6MREmzGx+B2DFpbH5rHlScLuNl1/X0ijDjT5le6BXNeook3DzRwd\n\tm0P5Ii7+f070cp7cVGRJ8+IMUrDyDjqrQ+FW+Wrhgcdg4zWhpHqfYoRkhJE0hy7yN7Q84GNdNBw\n\tfIc2abR3+UG79PzDla3fxTE=","Message-ID":"<5ed17a05-1dee-49c2-8d40-a1db8f67ef13@huawei.com>","Date":"Fri, 17 Apr 2026 08:48:31 +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 3/4] vfio/pci: Add PCIe TPH GET_ST interface","To":"Alex Williamson ","CC":"Wathsala Vithanage , ,\n\t, ","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n <20260415090959.53672-4-fengchengwen@huawei.com>\n <518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>\n <41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>\n <20260416074020.57e4ed72@shazbot.org>","Content-Language":"en-US","From":"fengchengwen ","In-Reply-To":"<20260416074020.57e4ed72@shazbot.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"kwepems100001.china.huawei.com (7.221.188.238) To\n kwepemk500009.china.huawei.com (7.202.194.94)"}},{"id":3678449,"web_url":"http://patchwork.ozlabs.org/comment/3678449/","msgid":"","list_archive_url":null,"date":"2026-04-17T02:06:38","subject":"Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface","submitter":{"id":92756,"url":"http://patchwork.ozlabs.org/api/people/92756/","name":"fengchengwen","email":"fengchengwen@huawei.com"},"content":"Sorry for the self-reply.\n\nHi Alex & Wathsala,\n\nBased on the VM assignment scenario and the cross-VM attack concern\nraised by Wathsala in her review of \"[PATCH v2 RESEND 4/5] vfio/pci: Add PCIe TPH GET_ST interface\":\n\n This is unsafe. A user space driver can obtain STs for arbitrary CPUs and program them\n into device-specific registers (e.g., E810), with no isolation guarantees.\n For example, consider two VMs on the same host. A driver in VM1 could program STs that\n target CPUs primarily used by VM2. This can steer traffic processing onto VM2's CPUs,\n creating contention and degrading VM2's performance.\n This breaks CPU isolation at the host level and can be used to disrupt workloads and violate\n SLAs across tenants.\n\nAfter fully re-evaluating the security architecture with your feedback,\nI agree with your concerns and conclusions. I hereby revoke my earlier\nproposal to restrict GET_ST to only the current CPU.\n\nFor devices that implement standard ST tables (via config space or MSI-X caps),\nhypervisors such as QEMU/kvmtool can trap and filter guest writes, preventing\nmalicious steering tag abuse. This is the safe and supported model for TPH in\nvirtualized environments.\n\nHowever, for devices that only support Device-Specific mode with no standard\nST table, there is no existing hypervisor interception mechanism to prevent\na guest from programming arbitrary steering tags to attack other CPUs.\nThis is a fundamental security risk that cannot be safely mitigated in software.\n\nTherefore, the correct security posture for virtualization is:\n- TPH should be enabled *only* for devices with standard ST tables\n- Devices without standard ST tables should NOT enable TPH in virtualization\n\nOn the other hand, in non-virtualization (bare-metal) scenarios, there is\nstrong legitimate demand for devices that lack a standard ST table —\nmany real-world devices are designed this way. For this reason, I would\nlike to retain the GET_ST interface.\n\nFor virtualization scenarios, the hypervisor is responsible for avoiding\nthis risk by **disabling TPH Requester Enable in the PCIe config space**,\nwhich is fully interceptable and under the hypervisor’s control.\n\nThanks\n\nOn 4/17/2026 8:48 AM, fengchengwen wrote:\n> Hi Alex,\n> \n> Thank you very much for your clear and detailed security explanation.\n> I fully understand and agree with your security concerns about allowing\n> userspace to query steering tags for arbitrary CPUs.\n> \n> To completely resolve this security issue while retaining the mandatory\n> functionality for DS-mode devices without ST table, I will revise the\n> GET_ST interface with a strict security constraint in v3:\n> \n> The CPU number provided by userspace will be VALIDATED TO EQUAL\n> THE CURRENT CALLING CPU of the ioctl().\n> \n> In other words:\n> - Userspace can ONLY query the steering tag for the CPU it is currently\n> running on.\n> - Userspace CANNOT query any other CPU.\n> - No cross-CPU probing, no side-channel, no attack surface.\n> - No ability to influence or target other CPUs.\n> \n> This completely eliminates the security exposure you mentioned, while\n> still fully supporting the Device-Specific mode requirement for devices\n> without ST tables.\n> \n> Thanks\n> \n> On 4/16/2026 9:40 PM, Alex Williamson wrote:\n>> On Thu, 16 Apr 2026 09:09:50 +0800\n>> fengchengwen wrote:\n>>\n>>> On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:\n>>>> Hi Feng,\n>>>>\n>>>> get_st  feature is unsafe. It allows a rogue userspace driver in device-specific\n>>>> mode to obtain steering tags for arbitrary CPUs, including ones unrelated\n>>>> to the device or its workload, enabling it to direct traffic into those CPUs’\n>>>> caches and potentially interfere with other workloads, opening doors to\n>>>> further exploits depending on other vulnerabilities. \n>>>\n>>> Thank you for the follow-up and for referencing the prior RFC\n>>> discussion on this topic. I appreciate you clarifying the\n>>> historical context of the safety concerns.\n>>>\n>>> I acknowledge the risks you’ve highlighted, but I believe the\n>>> risk profile in this VFIO interface is different and already\n>>> well bounded by existing design and practice:\n>>>\n>>> 1. VFIO device access requires elevated privileges\n>>> A userspace process can only open a VFIO device node if it\n>>> has sufficient privileges (typically root). This is not an\n>>> interface for unprivileged users.\n>>\n>> This argument is NOT helping your cause. This is not the usage model\n>> we design for. VFIO usage requires that privileges be granted to a\n>> user, in the form of device ACL access and locked memory, but does not\n>> generally require elevated privileges beyond that, or otherwise grant\n>> the user authority beyond the scope of the device. The root use case\n>> may be typical for you, but is not required for many other typical use\n>> cases, such as device assignment to VMs.\n>> \n>>> 2. In the thread \"[RFC v2 0/2] Retrieve tph from dmabuf for PCIe\n>>> P2P memory access\", applications can configure the steertag\n>>> of exported dmabufs from userspace to the kernel. Kernel PCIe\n>>> drivers (e.g., mlx5 NIC) then use these steertags and set them\n>>> to their ST tables. Even here, userspace could set invalid\n>>> steertags that impact GPU performance—but this model is\n>>> basically accepted I think (refer from maillist discuss).\n>>\n>> It's an RFC. It's bold to claim that it's nearly accepted.\n>>\n>>> 3. Malicious resource consumption is not unique to TPH\n>>> A malicious thread can be created to forcibly consume CPU\n>>> resources and bound to a specific CPU, affecting other CPUs.\n>>> This is a general system security concern, not one specific\n>>> to TPH GET_ST, and is addressed by existing system hardening\n>>> and access control mechanisms—not by removing useful features.\n>>\n>> You're conflating process abuse of a CPU to a potential side-channel\n>> DMA attach from a device. What *existing* hardening protects against\n>> the latter?\n>>\n>>> 4. GET_ST is strictly necessary for Device-Specific (DS) mode\n>>> when no ST table is present on the device.\n>>> For devices that do not have a dedicated ST table (a common\n>>> scenario in many PCIe endpoints), DS mode requires userspace\n>>> to retrieve per-CPU steering tags first, then program them\n>>> into the device’s steering logic via other registers. Without\n>>> GET_ST, userspace cannot obtain the required steertags to\n>>> enable TPH DS mode at all—rendering TPH support useless for\n>>> these devices. This is not an optional feature but a\n>>> fundamental requirement to unlock TPH functionality for a\n>>> large class of hardware.\n>>\n>> Unlocking a hardware feature does not give you authority to ignore the\n>> security implications of that feature. Thanks,\n>>\n>> Alex\n>","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=ZcBEeGEb;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52673-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=\"ZcBEeGEb\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=113.46.200.217","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 tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::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 4fxdY733Rxz1yGt\n\tfor ; Fri, 17 Apr 2026 12:06:51 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 15D393069BC4\n\tfor ; Fri, 17 Apr 2026 02:06:48 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id AD36428B40E;\n\tFri, 17 Apr 2026 02:06:44 +0000 (UTC)","from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com\n [113.46.200.217])\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 4E14417A309;\n\tFri, 17 Apr 2026 02:06:42 +0000 (UTC)","from mail.maildlp.com (unknown [172.19.162.144])\n\tby canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4fxdPL4YCkzcZyv;\n\tFri, 17 Apr 2026 10:00:06 +0800 (CST)","from kwepemk500009.china.huawei.com (unknown [7.202.194.94])\n\tby mail.maildlp.com (Postfix) with ESMTPS id CB3344056D;\n\tFri, 17 Apr 2026 10:06:39 +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, 17 Apr 2026 10:06:39 +0800"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776391604; cv=none;\n b=YfnTKhSu+Sg/OX+RfnO4PdRHwG+LlDrL8Op2JWaKUHXf8vhlczPKUk6LBDRXAX1OLiS4RYhJs/uheFRKiTEFrtuTox7zf+lLDIzKKbUqYJUworCdku/wCGmSTJDAUchkk79/LrQxoSDayXQQRREX7CPj8GpfiBF7rQLq1TmzPqA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776391604; c=relaxed/simple;\n\tbh=829qg2YfX/FUHVZ88E5VaY+MWknKv4R0cdh+zaquvlk=;\n\th=Message-ID:Date:MIME-Version:Subject:From:To:CC:References:\n\t In-Reply-To:Content-Type;\n b=tUwjXRmt/M94A3EgLbeGze5WIqu4j6ivB7AUva/jZeVahTe/FLY6j5HCgH+Ia5cTkNc9cHUSFPjkLMxPhAKK7HAc0BE4ZXkNgWfO17N8jDXbD/D+5AnFOVx6z1XdRfg8KcDYvhQkWGhaVQnhUxMoxT6F4Ig793A9Kpu4MDiH2sw=","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=ZcBEeGEb; arc=none smtp.client-ip=113.46.200.217","dkim-signature":"v=1; a=rsa-sha256; d=huawei.com; s=dkim;\n\tc=relaxed/relaxed; q=dns/txt;\n\th=From;\n\tbh=9t01x1EXAvJcCn3ApfdOi7NTYC+jaxcHb48nVyJFQc8=;\n\tb=ZcBEeGEbKqhTGKfr6uMwri7e76zmeYahi3Mf2vdxjLIFPvrCPUrH1I/+yvg0iVdnnJlxRwWvr\n\tLxEm9wT6BbHLcSDcDTnBhTOPV+AgPPvIwSzUpY8nInHEDgT6PpFmasvdRtPt8ALL9IByuBjk44D\n\ta45GV08SbNSi6S9kUs821ZU=","Message-ID":"","Date":"Fri, 17 Apr 2026 10:06:38 +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 3/4] vfio/pci: Add PCIe TPH GET_ST interface","From":"fengchengwen ","To":"Alex Williamson , Wathsala Vithanage\n\t","CC":", , ","References":"<20260415090959.53672-1-fengchengwen@huawei.com>\n <20260415090959.53672-4-fengchengwen@huawei.com>\n <518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>\n <41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com>\n <20260416074020.57e4ed72@shazbot.org>\n <5ed17a05-1dee-49c2-8d40-a1db8f67ef13@huawei.com>","Content-Language":"en-US","In-Reply-To":"<5ed17a05-1dee-49c2-8d40-a1db8f67ef13@huawei.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"kwepems200002.china.huawei.com (7.221.188.68) To\n kwepemk500009.china.huawei.com (7.202.194.94)"}}]