From: Bjorn Helgaas <helgaas@kernel.org>
To: Koichiro Den <den@valinux.co.jp>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
"Frank Li" <Frank.Li@nxp.com>,
"Niklas Cassel" <cassel@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Jon Mason" <jdmason@kudzu.us>,
"Dave Jiang" <dave.jiang@intel.com>,
"Allen Hubbe" <allenbh@gmail.com>,
linux-pci@vger.kernel.org, ntb@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] PCI: endpoint: pci-epf-vntb: Pass PF/VF number when BAR programming
Date: Wed, 9 Sep 2026 11:09:49 -0500 [thread overview]
Message-ID: <20260909160949.GA216221@bhelgaas> (raw)
In-Reply-To: <rmso2szdpfjy4qoqalhhpf3zxzn2te25m573qmwmpmoilk5jz2@arvvr4hdzbbj>
On Wed, Sep 09, 2026 at 01:53:53PM +0900, Koichiro Den wrote:
> On Tue, Sep 08, 2026 at 09:23:11PM -0500, Bjorn Helgaas wrote:
> > On Wed, Sep 09, 2026 at 11:01:48AM +0900, Koichiro Den wrote:
> > > On Tue, Sep 08, 2026 at 11:53:15AM -0500, Bjorn Helgaas wrote:
> > > > On Wed, Jul 29, 2026 at 02:23:04AM +0900, Koichiro Den wrote:
> > > > > vntb_epf_mw_set_trans() programs the memory-window BAR through
> > > > > pci_epc_set_bar() with hardcoded function numbers (0, 0), so the BAR
> > > > > lands on the wrong function whenever the vNTB EPF is bound to anything
> > > > > but PF0. The other BAR programming sites in the vNTB driver already pass
> > > > > the EPF's own numbers.
> > > > >
> > > > > Pass the EPF's own func_no/vfunc_no here as well.
> > > >
> > > > We're referring to these as "PF" and "VF" in the subject and "physical
> > > > endpoint function" and "virtual endpoint function" in the
> > > > pci_epc_set_bar() kernel-doc, but I don't think these have anything to
> > > > do with the SR-IOV PF and VF concepts, do they?
> > >
> > > Not in the specific case that motivated this series. But AFAICT, the EPC API
> > > uses the same (func_no, vfunc_no) pair to cover both ordinary functions and
> > > SR-IOV PFs/VFs scenarios. With vfunc_no == 0, func_no can identify either an
> > > ordinary function or an SR-IOV PF. A non-zero vfunc_no identifies a VF
> > > associated with the PF selected by func_no.
> >
> > Now I'm even more confused :)
> >
> > Are you saying that a non-zero vfunc_no always identifies an SR-IOV
> > VF? And there's some dependency on that? I don't any mention of
> > "iov" in drivers/pci/endpoint/.
>
> Yes, that is my understanding of the current in-tree implementation. You're
> right that drivers/pci/endpoint/ itself contains no explicit reference to
> SR-IOV. E.g. pci_epf_add_vepf() just calls it a "virtual EP function".
> So my saying was kind of assumptive, but I still think the same because:
>
> - The support was introduced for SR-IOV:
> https://lore.kernel.org/r/20210819123343.1951-1-kishon@ti.com/
>
> - The core rejects a non-zero vfunc_no unless the EPC provides max_vfs, and
> Cadence is the only in-tree EPC driver I found that does so. For example,
> cdns_pcie_ep_set_bar() calls cdns_pcie_get_fn_from_vfn(), which uses the
> SR-IOV First VF Offset and VF Stride for a non-zero vfn.
Thanks, that's helpful. I still have to work hard to change my point
of view from host-side drivers to endpoint drivers operating on the
other end of the link. The fact that there are several interfaces
that need (func_no, vfunc_no) suggests that callers really do need to
understand what's going on, and maybe we should try to connect the
kernel-doc and abbreviations more closely with PCIe spec terms.
E.g., if "physical EP function" and "virtual EP function" refer to
SR-IOV PF and VF, maybe we should word them as "endpoint PF" or
"endpoint VF" (or "EP PF", "EP VF" for short). If
"pci_epf_add_vepf()" adds an SR-IOV VF, maybe "pci_epf_add_vf()" would
be descriptive enough. We already know we're on the endpoint because
of "epf", so we probably don't need another hint in "vepf", which
includes a "pf" that doesn't mean SR-IOV PF.
> > > > I don't have a better naming suggestion, but this is slightly
> > > > confusing.
> > >
> > > Perhaps a better subject might be:
> > >
> > > PCI: endpoint: pci-epf-vntb: Pass (func_no, vfunc_no) when programming BARs
> > >
> > > Best regards,
> > > Koichiro
> > >
> > > >
> > > > > Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
> > > > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > > > ---
> > > > > drivers/pci/endpoint/functions/pci-epf-vntb.c | 3 ++-
> > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > > > > index c3caec927d74..fba65abfb6b2 100644
> > > > > --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > > > > +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > > > > @@ -1427,7 +1427,8 @@ static int vntb_epf_mw_set_trans(struct ntb_dev *ndev, int pidx, int idx,
> > > > > epf_bar->barno = barno;
> > > > > epf_bar->size = size;
> > > > >
> > > > > - ret = pci_epc_set_bar(ntb->epf->epc, 0, 0, epf_bar);
> > > > > + ret = pci_epc_set_bar(ntb->epf->epc, ntb->epf->func_no,
> > > > > + ntb->epf->vfunc_no, epf_bar);
> > > > > if (ret) {
> > > > > dev_err(dev, "failure set mw trans\n");
> > > > > return ret;
> > > > > --
> > > > > 2.51.0
> > > > >
next prev parent reply other threads:[~2026-09-09 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 17:23 [PATCH 0/3] PCI: endpoint: Support vNTB as a non-first EPF Koichiro Den
2026-07-28 17:23 ` [PATCH 1/3] PCI: endpoint: pci-epf-vntb: Pass PF/VF number when BAR programming Koichiro Den
2026-07-28 17:38 ` sashiko-bot
2026-07-28 19:18 ` Frank Li
2026-09-08 16:53 ` Bjorn Helgaas
2026-09-09 2:01 ` Koichiro Den
2026-09-09 2:23 ` Bjorn Helgaas
2026-09-09 4:53 ` Koichiro Den
2026-09-09 16:09 ` Bjorn Helgaas [this message]
2026-09-10 4:56 ` Koichiro Den
2026-09-10 6:08 ` Manivannan Sadhasivam
2026-09-10 8:26 ` Koichiro Den
2026-09-08 21:08 ` Bjorn Helgaas
2026-07-28 17:23 ` [PATCH 2/3] PCI: endpoint: pci-ep-msi: Make embedded doorbell IRQ exclusive Koichiro Den
2026-07-28 17:28 ` sashiko-bot
2026-07-28 19:23 ` Frank Li
2026-07-28 17:23 ` [PATCH 3/3] PCI: endpoint: pci-ep-msi: Let non-first EPFs use embedded doorbells Koichiro Den
2026-07-28 17:38 ` sashiko-bot
2026-07-28 19:26 ` Frank Li
2026-09-03 5:58 ` [PATCH 0/3] PCI: endpoint: Support vNTB as a non-first EPF Manivannan Sadhasivam
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=20260909160949.GA216221@bhelgaas \
--to=helgaas@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=allenbh@gmail.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=dave.jiang@intel.com \
--cc=den@valinux.co.jp \
--cc=jdmason@kudzu.us \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=ntb@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.