All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.