Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chengwen Feng" <fengchengwen@huawei.com>
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH RESEND v18 07/12] PCI/TPH: Add pcie_tph_supported() helper to check TPH capability attributes
Date: Tue, 23 Jun 2026 09:07:26 +0000	[thread overview]
Message-ID: <20260623090727.3FBFD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623085048.51139-8-fengchengwen@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `pcie_tph_supported()` helper ignores the system-wide `pci_tph_disabled` flag, causing VFIO to incorrectly expose an unusable TPH capability to guests.
--

commit 8a6b48383e4674ff26e8119bccd07a94e9e6b180
Author: Chengwen Feng <fengchengwen@huawei.com>

PCI/TPH: Add pcie_tph_supported() helper to check TPH capability attributes

This commit adds the pcie_tph_supported() helper to check if a PCI device
has a valid TPH capability or Extended TPH support. The helper is intended
for use by VFIO to query TPH existence and capabilities uniformly.

> diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c
> --- a/drivers/pci/tph.c
> +++ b/drivers/pci/tph.c

[ ... ]

> @@ -596,3 +596,22 @@ void pci_tph_init(struct pci_dev *pdev)
>  	save_size = sizeof(u32) + num_entries * sizeof(u16);
>  	pci_add_ext_cap_save_buffer(pdev, PCI_EXT_CAP_ID_TPH, save_size);
>  }

[ ... ]

> +/**
> + * pcie_tph_supported - Check TPH capability attribute
> + * @pdev: PCI device to query
> + * @want_ext: false - check TPH cap exists; true - check EXT_TPH support
> + *
> + * Return: true on matched condition, false otherwise
> + */
> +bool pcie_tph_supported(struct pci_dev *pdev, bool want_ext)
> +{
> +	if (!pdev->tph_cap)
> +		return false;
> +

[Severity: Medium]
Should this function also check the system-wide pci_tph_disabled flag?

If the host administrator explicitly disables TPH via the notph boot
parameter, pci_tph_disabled is set to true. Because this helper only
checks pdev->tph_cap, it appears VFIO will still evaluate this as true
and expose a "zombie" TPH capability to guests.

The guest would see the capability but silently fail to enable it since
VFIO's configuration intercept correctly enforces pci_tph_disabled.

Would it be better to return false here if pci_tph_disabled is set, so
we respect the administrator's global disable intent and avoid exposing
unusable capabilities to guests?

> +	if (!want_ext)
> +		return true;
> +
> +	return pdev->tph_ext_support;
> +}
> +EXPORT_SYMBOL(pcie_tph_supported);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623085048.51139-1-fengchengwen@huawei.com?part=7

  reply	other threads:[~2026-06-23  9:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  8:50 [PATCH RESEND v18 00/12] vfio/pci: Add PCIe TPH support Chengwen Feng
2026-06-23  8:50 ` [PATCH RESEND v18 01/12] PCI/TPH: Fix pcie_tph_get_st_table_loc() field extraction Chengwen Feng
2026-06-23  8:59   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 02/12] PCI/TPH: Fix tph_enabled concurrent update race by bitfield packing Chengwen Feng
2026-06-23  9:00   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 03/12] PCI/TPH: Cache TPH requester capability at probe time Chengwen Feng
2026-06-23  9:00   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 04/12] PCI/TPH: Refactor pcie_enable_tph & add explicit requester variant Chengwen Feng
2026-06-23  9:04   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 05/12] PCI/TPH: Refactor pcie_tph_get_cpu_st & add explicit variant Chengwen Feng
2026-06-23  9:02   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 06/12] PCI/TPH: Expose the enabled TPH requester type Chengwen Feng
2026-06-23  8:57   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 07/12] PCI/TPH: Add pcie_tph_supported() helper to check TPH capability attributes Chengwen Feng
2026-06-23  9:07   ` sashiko-bot [this message]
2026-06-23  8:50 ` [PATCH RESEND v18 08/12] PCI/TPH: Add sysfs binary file to export CPU to steering-tag mapping Chengwen Feng
2026-06-23  9:02   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 09/12] vfio/pci: Hide TPH capability when TPH is unsupported Chengwen Feng
2026-06-23  9:07   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 10/12] vfio/pci: Add TPH_ENABLE feature skeleton and unsafe module parameter Chengwen Feng
2026-06-23  9:03   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 11/12] vfio/pci: Add TPH_ST_CONFIG for PCIe TPH ST configuration Chengwen Feng
2026-06-23  9:11   ` sashiko-bot
2026-06-23  8:50 ` [PATCH RESEND v18 12/12] vfio/pci: Virtualize PCIe TPH capability registers Chengwen Feng
2026-06-23  9:13   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260623090727.3FBFD1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=fengchengwen@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox