Re: [PATCH v2 0/3] PCI: endpoint: Support hardware-owned MSI-X table and PBA

[Koichiro Den]

On Wed, Sep 02, 2026 at 09:25:13AM +0200, Niklas Cassel wrote:
> On Wed, Sep 02, 2026 at 11:14:00AM +0900, Koichiro Den wrote:
> > 
> > This still sounds really odd, and it does not obviously explain why both DWORDs
> > at 0x4000 and 0x4004 are affected. I may be missing something important. If
> > anything similar involving iMSIX-TX Table RAM entry #0 has been discussed
> > before, please point me to the relevant thread.
> > 
> > (Also, I can share my current WIP v3 series, which makes pci-epf-test and
> > nvmet-pci-epf use the hardware-owned layout when available, while leaving
> > pci-epf-ntb with its EPF-owned layout. If you have any setup where you could
> > test it, please let me know.)
> 
> Some time ago, I did verify that I could raise an IRQ using
> dw_pcie_ep_raise_msix_irq_doorbell(). If I remember correctly, I did so using
> pci-epf-test and not nvmet-pci-epf.
> 
> Did pci-epf-test work? (From what you explain, it seems to be related to if
> MSI-X Table entry #0 is used or not.)
> 
> Please share your branch. I should have time to do a quick test.
> 
> 
> > 
> > > 
> > > 
> > > What I suggest that you instead do something like:
> > > Patch 1/7: pci-epf-vntb: Fix to actually use MSI-X when requested.
> > >            This probably includes adding the code that is inside the
> > > 	   if (ret == -ENOENT) { }.
> > > Patch 2/7: PCI: endpoint: Support hardware-owned MSI-X table and PBA
> > > Patch 3/7: PCI: dw-rockchip: Support fixed MSI-X table and PBA on RK3588
> > > Patch 4/7: pci-epf-vntb: Add code that calls pci_epc_get_hw_msix_layout()
> > >            and uses that layout, if the function returned success.
> > > Patch 5/7: pci-epf-test: Add code that calls pci_epc_get_hw_msix_layout()
> > >            and uses that layout, if the function returned success.
> > > Patch 6/7: nvmet-pci-epf: Add code that calls pci_epc_get_hw_msix_layout()
> > >            and uses that layout, if the function returned success.
> > > Patch 7/7: pci-epf-ntb: Add comment that explains why it cannot call
> > >            pci_epc_get_hw_msix_layout() like all other EPF drivers that
> > > 	   support MSI-X.
> > > 
> > > 
> > > This way, patch 1/7 can be backported, and will help all users vNTB users,
> > > even the users that do not use RK3588 as an EPC.
> > 
> > That split makes sense. However, given the issue I described above, perhaps I
> > should send patch 1/7 as a standalone fix and hold off on the rest until the
> > issue is understood and resolved.
> 
> Agreed, a standalone 1/7 patch could be picked up without the need to wait for
> any other changes.
> 
> 
> > 
> > Testing vNTB alone (ie. this v2 way) did not expose it because its first data
> > doorbell uses MSI-X Table entry #2. I only found the issue because your
> > suggestion led me to convert and test nvmet-pci-epf, thank you!
> 
> I'm sorry that we have a problem.
> At least it is better to discover it now, rather than discovering it after
> the patches had been merged.

Hello Niklas,

Thanks. Better safe than sorry.

For context, this series is not directly part of the NTB transport direct TX/RX
work I'm working on. Now that we've chosen vNTB-DMA instead of PCI DMA EPF, as
you know, its test coverage can naturally extend beyond my main target, R-Car
S4, to other platforms. Which includes RK3588, that I am sure you know really
well and which I can test on my Rock 5B. That is what led me to look at the
RK3588 MSI-X path now. In short, even if v3 path 1 or patch 2-7 take time to
land, that will not block the direct TX/RX work.

Please save the text between the markers as an mbox and apply it with git am.

------------8<----(from here)------8<-------------