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. 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. Kind regards, Niklas
