All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Wei Wang <wei.w.wang@hotmail.com>
Cc: <bhelgaas@google.com>, <jgg@nvidia.com>,
	<akpm@linux-foundation.org>, <bp@alien8.de>,
	<rdunlap@infradead.org>, <alex@shazbot.org>,
	<kevin.tian@intel.com>, <linux-kernel@vger.kernel.org>,
	<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v4 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()
Date: Mon, 9 Feb 2026 16:50:14 +0000	[thread overview]
Message-ID: <20260209165014.000070da@huawei.com> (raw)
In-Reply-To: <SI2PR01MB43931402377765D5DEA04ED3DC65A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>

On Sat,  7 Feb 2026 19:30:59 +0800
Wei Wang <wei.w.wang@hotmail.com> wrote:

> The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
> isolation. On devices that support the PCI_ACS_ECAP capability, the
> controls are required to be enabled properly:
> - ACS I/O Request Blocking needs to be enabled to avoid unintended
>   upstream I/O requests.
> - ACS DSP and USP Memory Target Access Control needs to be set with
>   Request Redirect or Request Blocking to ensure the Downstream and
>   Upstream Port memory resource ranges are not accessed by upstream
>   memory requests.
> - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
>   areas that lies within a Switch's Upstream Port memory apertures but not
>   within any Downstream Port memory apertures get redirected.
> 
> To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
> support, pci_acs_enabled() skips checking for the capability.
> 
> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
Hi Wei Wang,

A few things inline.

Thanks,

Jonathan

> ---
>  drivers/pci/pci.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 1714e29ce099..53e79948b4ea 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c

> +static bool pci_acs_ecap_enabled(struct pci_dev *pdev, u16 ctrl)
> +{
> +	bool is_dsp = pci_pcie_type(pdev) == PCI_EXP_TYPE_DOWNSTREAM;
> +	struct pci_dev *usp_pdev = pci_upstream_bridge(pdev);
> +	u16 mask = PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR;
> +
> +	/*
> +	 * For ACS DSP/USP Memory Target Access Control, either Request
> +	 * Redirect or Request Blocking must be enabled to enforce isolation.
> +	 * According to PCIe spec 7.0, the DSP Memory Target Access is
> +	 * applicable to both Root Ports and Switch Upstream Ports that have
> +	 * applicable Memory BAR space to protect. So if the device does not
> +	 * have a Memory BAR, it skips the check.
> +	 */
> +	if (pci_dev_has_memory_bars(pdev) &&
> +	    (ctrl & mask) != PCI_ACS_DMAC_RB &&
> +	    (ctrl & mask) != PCI_ACS_DMAC_RR)

As below. I'd use the mask define suggested in previous then FIELD_GET()
plus checking the value of that against defines for these two field
values.

> +		return false;
> +
> +	mask = PCI_ACS_UMAC_RB | PCI_ACS_UMAC_RR;
This is the mask for the field that should be in the header.
> +	/*
> +	 * The USP Memory Target Access is only applicable to downstream ports
> +	 * that have applicable Memory BAR space in the Switch Upstream Port to
> +	 * protect.
> +	 */
> +	if (is_dsp && pci_dev_has_memory_bars(usp_pdev) &&
> +	    (ctrl & mask) != PCI_ACS_UMAC_RB &&
> +	    (ctrl & mask) != PCI_ACS_UMAC_RR)
> +		return false;
> +
> +	/* PCI_ACS_URRC is applicable to Downstream Ports only.  */
> +	if (is_dsp && !(ctrl & PCI_ACS_URRC))
> +		return false;

I'd be tempted to group the DSP specific handling and drop the local variable.

	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_DOWNSTREAM) {
		if (pci_dev_has_memory_bars(usp_pdev) &&
		    (ctrl & mask) != PCI_ACS_UMAC_RB &&
		    (ctrl & mask) != PCI_ACS_UMAC_RR)
// or use FIELD_GET() to get using the mask suggested in previous patch then
// match what was in the filed here.
			return false;
	
		if (!(ctrl & PCI_ACS_URRC))
			return false;
	}
> +
> +	/* PCI_ACS_IB is applicable to both Root and Downstream Ports. */
> +	return !!(ctrl & PCI_ACS_IB);
> +}
> +



  reply	other threads:[~2026-02-09 16:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-07 11:30 [PATCH v4 0/2] PCI: Add support for ACS Enhanced Capability Wei Wang
2026-02-07 11:30 ` [PATCH v4 1/2] PCI: Enable the enhanced ACS controls introduced by PCI_ACS_ECAP Wei Wang
2026-02-09 16:43   ` Jonathan Cameron
2026-02-10 15:02     ` Wei Wang
2026-02-07 11:30 ` [PATCH v4 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled() Wei Wang
2026-02-09 16:50   ` Jonathan Cameron [this message]
2026-02-10 15:06     ` Wei Wang

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=20260209165014.000070da@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=wei.w.wang@hotmail.com \
    /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.