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 12/12] vfio/pci: Virtualize PCIe TPH capability registers
Date: Tue, 23 Jun 2026 09:13:03 +0000	[thread overview]
Message-ID: <20260623091304.5B4471F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260623085048.51139-13-fengchengwen@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unchecked return value from `pcie_tph_set_st_entry()` causes state desynchronization between the virtual config space and physical hardware.
--

commit 94cd790796325d732c4348b7bef18a12078f330c
Author: Chengwen Feng <fengchengwen@huawei.com>

vfio/pci: Virtualize PCIe TPH capability registers

This commit virtualizes the TPH extended capability config space registers.
It splits permissions, blocks direct ST-table programming via config space,
and syncs the cached shadow ST table to physical hardware when the TPH
requester is enabled.

> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index 5c6ab172df6c0..10f4e9fabea7c 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c

[ ... ]

> +static int vfio_tph_config_write(struct vfio_pci_core_device *vdev, int pos,
> +				 int count, struct perm_bits *perm,
> +				 int offset, __le32 val)
> +{

[ ... ]

> +	if (req == PCI_TPH_REQ_TPH_ONLY || req == PCI_TPH_REQ_EXT_TPH) {
> +		extended = !!(req == PCI_TPH_REQ_EXT_TPH);
> +		ret = pcie_enable_tph_explicit(pdev, mode, extended);
> +		if (!ret && vdev->tph_st_shadow) {
> +			for (i = 0; i < vdev->tph_st_entries; i++)
> +				pcie_tph_set_st_entry(pdev, i,
> +						      vdev->tph_st_shadow[i]);

[Severity: Medium]
Should this loop check the return value of pcie_tph_set_st_entry()?

If syncing the Steering Tag (ST) table fails (for example, due to MSI-X
table access errors), pcie_tph_set_st_entry() disables TPH on the physical
hardware and returns an error code. 

Because the return value is ignored here, it skips the rollback of the
virtual config space that would happen if ret was updated.

Could this result in the guest OS incorrectly believing TPH is enabled,
leading to an inconsistent state between the physical hardware and the
virtual config space?

> +		}
> +		if (ret)
> +			vfio_default_config_write(vdev, pos, count, perm,
> +						  offset, org_val);
> +	} else if (req == PCI_TPH_REQ_DISABLE) {
> +		pcie_disable_tph(vdev->pdev);
> +	} else {
> +		vfio_default_config_write(vdev, pos, count, perm, offset,
> +					  org_val);
> +	}
> +
> +	up_write(&vdev->memory_lock);
> +
> +	return count;
> +}

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

      reply	other threads:[~2026-06-23  9:13 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
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 [this message]

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=20260623091304.5B4471F00A3A@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