linux-kernel - Re: [PATCH v8 0/5] PCI: endpoint: BAR subrange mapping support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <t2hsk77mp3shacbehlqfnpjgc4az2phvo2cyjn5hkybqdmzrcj@hnuwporebhz2>
Date: Fri, 23 Jan 2026 23:08:39 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Niklas Cassel <cassel@...nel.org>
Cc: Manivannan Sadhasivam <mani@...nel.org>, bhelgaas@...gle.com, 
	kwilczynski@...nel.org, frank.li@....com, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/5] PCI: endpoint: BAR subrange mapping support

On Fri, Jan 23, 2026 at 09:35:01AM +0100, Niklas Cassel wrote:
> On Fri, Jan 23, 2026 at 04:11:08PM +0900, Koichiro Den wrote:
> > 
> > One additional concern if we were to add a subrange mapping test is that
> > the EP-side pci-epf-test.c currently defines bar_size as follows:
> > 
> >   static size_t bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> >   (see https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/endpoint/functions/pci-epf-test.c#L105)
> > 
> > The values 512 (BAR0/1) and 1024 (BAR2) are even smaller than the minimam
> > CX_ATU_MIN_REGION_SIZE (=4KB). This means that introducing
> > BAR_SUBRANGE_TEST would likely require one of the following:
> > 
> >   (a). raising these hard-coded values
> >   (b). reserving a dedicated BAR for the subrange mapping test
> >   (c). limiting the testing to BAR3/4/5 if available (though, for
> >        example, no BAR would pass the test on R-Car Spider which I'm
> >        testing on, where BAR4 is fixed 256B).
> > 
> > I'm wondering whether there is a clean way to add a subrange mapping test
> > without significantly reshaping pci-epf-test.
> 
> If you really want to implement a test, I suggest to look at:

Honestly, I hadn't thought of it until receiving your comment in this
thread, since [1] through [2] already cover the relevant testing. But on
second thought, that might be too heavy-weight, and instead adding just a
simple test for subrange mapping in this series, might suffice.

[1] https://lore.kernel.org/all/20260118135440.1958279-37-den@valinux.co.jp/
[2] https://lore.kernel.org/all/20260118135440.1958279-39-den@valinux.co.jp/

> 
> pci_epf_test_enable_doorbell()
> Which changes the address translation of a BAR dynamically.
> 
> pci_epf_test_disable_doorbell()
> Which reverts back to the original translation.
> 
> pci_epf_test_enable_doorbell() simply does:
> pci_epc_get_next_free_bar() to get a BAR, then writes the BAR
> number in the in the pci-epf-test command registers, offset:
> PCI_ENDPOINT_TEST_DB_BAR                0x34
> 
> (Which represent the offset in struct pci_epf_test, for
> struct member db_bar)
> 
> 
> However, the doorbells are most likely very small, so the chances
> that reg->doorbell_offset will have a value that is smaller than
> BAR size seems likely... but not guaranteed... and there is no
> 
> if (reg->doorbell_offset > epf->bar[bar].size)
>     goto err_doorbell_cleanup;
> 
> So it seems that this doorbell test just ignores the problem...
> 
> Frank, could you perhaps send a patch to add something like the above?
> 
> 
> For your case... I guess we could bump the default sizes in pci-epf-test
> if we want to. pci-epf-test already does:
> 
>                 if (epc_features->bar[bar].type == BAR_FIXED)
>                         test_reg_size = epc_features->bar[bar].fixed_size;
>                 else
>                         test_reg_size = bar_size[bar];
> 
> So if there are fixed size BARs, that size will be respected, so I don't
> think there should be any problem to increase the default sizes, if we
> wanted to.
> 
> E.g. RK3588 has CX_ATU_MIN_REGION_SIZE 64k
> 
> So if we wanted to, a good number would be to have at least a few BARs of size
> 128k or larger (so there could be two submaps), since I assume that some other
> DWC controllers might also have have 64k min alignment.

I'm not entirely sure whether it's really acceptable to bump the hard-coded
sizes for BAR0/1/2/3 (512, 512, 1024, 16384) to 128k, in other words,
whether there were any reasons behind choosing such small default numbers.
Let's see. I agree that 128k or larger should suffice for DWC-based
platforms (as you mentioned, testing with two submaps).

> 
> 
> Having a test for this feature in pci-epf-test sounds really nice.
> You could have even add a capability for this, see
> pci_epf_test_set_capabilities().
> 
> if (epf_test->epc_features->subrange_mapping)
> 	caps |= CAP_SUBRANGE_MAPPING;
> 
> 
> Such that the host side driver (drivers/misc/pci_endpoint_test.c) could return
> a distinct error code when this feature is not supported, such that
> tools/testing/selftests/pci_endpoint/pci_endpoint_test.c could return SKIP when
> that distinct error code is detected.

That sounds nice.

Thanks,
Koichiro

> 
> 
> Kind regards,
> Niklas