All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: iommu@lists.linux.dev, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	David Matlack <dmatlack@google.com>,
	Samiullah Khawaja <skhawaja@google.com>,
	Daniel Mentz <danielmentz@google.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Mostafa Saleh <smostafa@google.com>,
	Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH v4 2/5] PCI/ATS: Validate STU for VFs in pci_prepare_ats()
Date: Thu, 28 May 2026 20:27:52 +0000	[thread overview]
Message-ID: <ahilSL7sGb1pnq5I@google.com> (raw)
In-Reply-To: <ahSnLeKchpPbz1m9@Asurada-Nvidia>

On Mon, May 25, 2026 at 12:46:53PM -0700, Nicolin Chen wrote:
> On Mon, May 25, 2026 at 06:43:44PM +0000, Pranjal Shrivastava wrote:
> > While every PCI Function that implements ATS has an independent ATS
> > Extended Capability structure with a Read/Write Smallest Translation
> > Unit (STU) field, the kernel manages SR-IOV ATS by requiring the IOMMU
> > driver to configure the STU on the Physical Function (PF) before any
> > any Virtual Functions (VFs) are created.
> > 
> > Currently, pci_prepare_ats() bails out early for VFs, assuming that the
> > PF has already been correctly prepared. However, this creates a potential
> > mismatch if a VF is subsequently prepared with a different page shift.
> > 
> > Update pci_prepare_ats() to validate that the requested page shift (ps)
> > matches the STU already configured in the associated PF. This ensures
> > early detection of incompatible configurations and maintains the kernel's
> > policy of consistent STU sizing across all functions associated with a
> > given SMMU.
> > 
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
> > Signed-off-by: Pranjal Shrivastava <praan@google.com>
> 
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> 
> Nit:
> 
> > @@ -73,8 +73,13 @@ int pci_prepare_ats(struct pci_dev *dev, int ps)
> >  	if (ps < PCI_ATS_MIN_STU)
> >  		return -EINVAL;
> >  
> > -	if (dev->is_virtfn)
> > +	if (dev->is_virtfn) {
> > +		struct pci_dev *pdev = pci_physfn(dev);
> > +
> > +		if (pdev->ats_stu != ps)
> > +			return -EINVAL;
> >  		return 0;
> > +	}
> 
> pdev doesn't seem useful. Dropping it reads better to me:
> 		if (pci_physfn(dev)->ats_stu != ps)
> 			return -EINVAL;

Ahh, I missed this nit in the v5 I just posted. I'll surely address this
in the next revision.

Thanks,
Praan


  reply	other threads:[~2026-05-28 20:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25 18:43 [PATCH v4 0/5] iommu: Standardize ATS robustness and state tracking Pranjal Shrivastava
2026-05-25 18:43 ` [PATCH v4 1/5] PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs Pranjal Shrivastava
2026-05-25 19:42   ` Nicolin Chen
2026-05-25 18:43 ` [PATCH v4 2/5] PCI/ATS: Validate STU for VFs in pci_prepare_ats() Pranjal Shrivastava
2026-05-25 19:46   ` Nicolin Chen
2026-05-28 20:27     ` Pranjal Shrivastava [this message]
2026-05-25 18:43 ` [PATCH v4 3/5] iommu/arm-smmu-v3: Fix ATS state tracking Pranjal Shrivastava
2026-05-25 20:05   ` Nicolin Chen
2026-05-25 20:30     ` Pranjal Shrivastava
2026-05-25 20:40       ` Nicolin Chen
2026-05-25 20:24   ` sashiko-bot
2026-05-25 18:43 ` [PATCH v4 4/5] iommu/vt-d: Fail probe on ATS configuration failure Pranjal Shrivastava
2026-05-25 20:56   ` sashiko-bot
2026-05-28  5:19     ` Baolu Lu
2026-05-28 17:36       ` Pranjal Shrivastava
2026-05-25 18:43 ` [PATCH v4 5/5] iommu/amd: " Pranjal Shrivastava
2026-05-25 21:35   ` 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=ahilSL7sGb1pnq5I@google.com \
    --to=praan@google.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=danielmentz@google.com \
    --cc=dmatlack@google.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=robin.murphy@arm.com \
    --cc=skhawaja@google.com \
    --cc=smostafa@google.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@kernel.org \
    /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.