On Mon, Mar 16, 2026 at 02:29:54PM +0100, Christian Bruel wrote: > > > On 3/16/26 13:57, Niklas Cassel wrote: > > On Mon, Mar 16, 2026 at 01:41:03PM +0100, Christian Bruel wrote: > > > Hi Koichiro, > > > > > > > > > > > If I understood the problem correctly, would something like the patch > > > > below > > > > address it? My expectation is that the subrange mapping test would then > > > > fail > > > > consistently on platforms that do not have enough free IB iATU regions. > > > > > > > > > > Thank you for your patch. Yes, now the bar subrange tests fail > > > consistently, > > > so that is enough to say this is not a regression. > > > > > > However, I think there was a clear BAR missing somewhere before running > > > the > > > tests in the EPF driver, as the BARs could be reallocated during the other > > > tests. This is not due to the subrange tests, but the EPF test driver > > > supposes a 1:1 BAR/ATU mapping. Now this assumption is broken. I'm > > > wondering > > > if this could be improved to make the subrange tests pass on all platforms > > > > Normally, you want one inbound iATU per enabled BAR, since you want the host > > to be able to access all the enabled BARs at any time. > > > > If you are thinking that we should somehow temporarily disable inbound > > address translation for one of the enabled BARs, such that we can do "steal" > > that iATU to test inbound subrange mapping, then I think that is a bad idea. > > yes, I was thinking something about restricting the iATU entry lifetime > during the BAR test duration and restoring after. But OK I agree, not good. > > > > > I think we should just let the test fail. Possibly we could call some API > > that > > tells us that all inbound iATUs are occupied, and then SKIP instead of FAIL > > the inbound subrange test case. > > > > If you really want to test/use inbound subrange mapping, even if your SoC > > has > > a very limited number of inbound iATUs, then I think a better solution is to > > mark one or multiple of your BARs as disabled: > > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9 > > > > Then you should have at least one more inbound iATU available, and should be > > able to run the inbound subrange test case. > > Yes cherry-picking the BAR_DISABLED support, I can now test the subrange > with Koichiro's fixup. > > ./pci_endpoint_test -t BAR_SUBRANGE_TEST > TAP version 13 > 1..6 > # Starting 6 tests from 6 test cases. > # RUN pci_ep_bar.BAR0.BAR_SUBRANGE_TEST ... > # SKIP BAR is test register space > # OK pci_ep_bar.BAR0.BAR_SUBRANGE_TEST > ok 1 pci_ep_bar.BAR0.BAR_SUBRANGE_TEST # SKIP BAR is test register space > # RUN pci_ep_bar.BAR1.BAR_SUBRANGE_TEST ... > # OK pci_ep_bar.BAR1.BAR_SUBRANGE_TEST > ok 2 pci_ep_bar.BAR1.BAR_SUBRANGE_TEST > # RUN pci_ep_bar.BAR2.BAR_SUBRANGE_TEST ... > # OK pci_ep_bar.BAR2.BAR_SUBRANGE_TEST > ok 3 pci_ep_bar.BAR2.BAR_SUBRANGE_TEST > # RUN pci_ep_bar.BAR3.BAR_SUBRANGE_TEST ... > # SKIP BAR is disabled > # OK pci_ep_bar.BAR3.BAR_SUBRANGE_TEST > ok 4 pci_ep_bar.BAR3.BAR_SUBRANGE_TEST # SKIP BAR is disabled > # RUN pci_ep_bar.BAR4.BAR_SUBRANGE_TEST ... > # SKIP BAR is disabled > # OK pci_ep_bar.BAR4.BAR_SUBRANGE_TEST > ok 5 pci_ep_bar.BAR4.BAR_SUBRANGE_TEST # SKIP BAR is disabled > # RUN pci_ep_bar.BAR5.BAR_SUBRANGE_TEST ... > # SKIP BAR is disabled > # OK pci_ep_bar.BAR5.BAR_SUBRANGE_TEST > ok 6 pci_ep_bar.BAR5.BAR_SUBRANGE_TEST # SKIP BAR is disabled > # PASSED: 6 / 6 tests passed. > # 4 skipped test(s) detected. Consider enabling relevant config options to > improve coverage. > # Totals: pass:2 fail:0 xfail:0 xpass:0 skip:4 error:0 > > Thank you,
Christian, thank you for testing. Niklas, thank you for the follow-up. I agree with your assessment. Bjorn, I'll submit the tested-patch shortly. Sorry for the trouble. Best regards, Koichiro > > Christian > > > > > > Kind regards, > > Niklas >
