diff options
| author | Danilo Krummrich <dakr@kernel.org> | 2026-08-13 18:52:04 +0200 |
|---|---|---|
| committer | Danilo Krummrich <dakr@kernel.org> | 2026-08-17 01:41:36 +0200 |
| commit | f146c7bc85a51f95c05e0f8173d484eb301ece78 (patch) | |
| tree | 07296ae54ed6551492b0c609dc0f5463f61f89ca /tools/testing/memblock/README | |
| download | linux-stable-f146c7bc85a51f95c05e0f8173d484eb301ece78.tar.gz linux-stable-f146c7bc85a51f95c05e0f8173d484eb301ece78.zip | |
PCI: Add pci_irq_type() to query the allocated interrupt typegrafted
Add a helper that returns PCI_IRQ_MSIX, PCI_IRQ_MSI, or PCI_IRQ_INTX
based on the interrupt type the PCI core selected after
pci_alloc_irq_vectors().
Several drivers already open-code this check against pdev->msix_enabled
and pdev->msi_enabled, or even open code this helper [1].
A common helper avoids the duplication and keeps drivers from accessing
the bitfield directly (see also [2]).
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: John Hubbard <jhubbard@nvidia.com>
Link: https://elixir.bootlin.com/linux/v7.1/source/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c#L196 [1]
Inspired-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/all/DKKG2QM3YJYB.Z2H2B2UXJ75N@kernel.org/ [2]
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260813165234.620555-5-dakr@kernel.org
[ Add missing pci_irq_type() stub for CONFIG_PCI=n. ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Diffstat (limited to 'tools/testing/memblock/README')
| -rw-r--r-- | tools/testing/memblock/README | 115 |
1 files changed, 115 insertions, 0 deletions
diff --git a/tools/testing/memblock/README b/tools/testing/memblock/README new file mode 100644 index 000000000..b435f48d8 --- /dev/null +++ b/tools/testing/memblock/README @@ -0,0 +1,115 @@ +================== +Memblock simulator +================== + +Introduction +============ + +Memblock is a boot time memory allocator[1] that manages memory regions before +the actual memory management is initialized. Its APIs allow to register physical +memory regions, mark them as available or reserved, allocate a block of memory +within the requested range and/or in specific NUMA node, and many more. + +Because it is used so early in the booting process, testing and debugging it is +difficult. This test suite, usually referred as memblock simulator, is +an attempt at testing the memblock mechanism. It runs one monolithic test that +consist of a series of checks that exercise both the basic operations and +allocation functionalities of memblock. The main data structure of the boot time +memory allocator is initialized at the build time, so the checks here reuse its +instance throughout the duration of the test. To ensure that tests don't affect +each other, region arrays are reset in between. + +As this project uses the actual memblock code and has to run in user space, +some of the kernel definitions were stubbed by the initial commit that +introduced memblock simulator (commit 16802e55dea9 ("memblock tests: Add +skeleton of the memblock simulator")) and a few preparation commits just +before it. Most of them don't match the kernel implementation, so one should +consult them first before making any significant changes to the project. + +Usage +===== + +To run the tests, build the main target and run it: + +$ make && ./main + +A successful run produces no output. It is possible to control the behavior +by passing options from command line. For example, to include verbose output, +append the `-v` options when you run the tests: + +$ ./main -v + +This will print information about which functions are being tested and the +number of test cases that passed. + +For the full list of options from command line, see `./main --help`. + +It is also possible to override different configuration parameters to change +the test functions. For example, to simulate enabled NUMA, use: + +$ make NUMA=1 + +For the full list of build options, see `make help`. + +Project structure +================= + +The project has one target, main, which calls a group of checks for basic and +allocation functions. Tests for each group are defined in dedicated files, as it +can be seen here: + +memblock +|-- asm ------------------, +|-- lib |-- implement function and struct stubs +|-- linux ------------------' +|-- scripts +| |-- Makefile.include -- handles `make` parameters +|-- tests +| |-- alloc_api.(c|h) -- memblock_alloc tests +| |-- alloc_helpers_api.(c|h) -- memblock_alloc_from tests +| |-- alloc_nid_api.(c|h) -- memblock_alloc_try_nid tests +| |-- basic_api.(c|h) -- memblock_add/memblock_reserve/... tests +| |-- common.(c|h) -- helper functions for resetting memblock; +|-- main.c --------------. dummy physical memory definition +|-- Makefile `- test runner +|-- README +|-- TODO +|-- .gitignore + +Simulating physical memory +========================== + +Some allocation functions clear the memory in the process, so it is required for +memblock to track valid memory ranges. To achieve this, the test suite registers +with memblock memory stored by test_memory struct. It is a small wrapper that +points to a block of memory allocated via malloc. For each group of allocation +tests, dummy physical memory is allocated, added to memblock, and then released +at the end of the test run. The structure of a test runner checking allocation +functions is as follows: + +int memblock_alloc_foo_checks(void) +{ + reset_memblock_attributes(); /* data structure reset */ + dummy_physical_memory_init(); /* allocate and register memory */ + + (...allocation checks...) + + dummy_physical_memory_cleanup(); /* free the memory */ +} + +There's no need to explicitly free the dummy memory from memblock via +memblock_free() call. The entry will be erased by reset_memblock_regions(), +called at the beginning of each test. + +Known issues +============ + +1. Tests for memblock_alloc_low() can't be easily implemented. The function uses + ARCH_LOW_ADDRESS_LIMIT marco, which can't be changed to point at the low + memory of the memory_block. + +References +========== + +1. Boot time memory management documentation page: + https://www.kernel.org/doc/html/latest/core-api/boot-time-mm.html |
