Re: [PATCH 1/4] Documentation/driver-api/cxl: Add a testing page

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 14 Oct 2026 14:34:44 -0700
Alison Schofield <alison.schofield@intel.com> wrote:

> On Tue, Oct 13, 2026 at 09:17:52PM -0700, Alison Schofield wrote:
> > The CXL documentation does not describe the subsystem's testing
> > infrastructure or provide guidance on choosing between cxl_test
> > and KUnit.
> > 
> > Add a testing page that describes when to use each framework, how
> > to run the tests, and how to add a CXL KUnit test.  
> 
> Gaobin's question about updating the CMD_CMD_RC_TABLE w the new 4.0
> definitions made me realize this doc could use some words around
> maintaining the kunit tests, ie keeping them running.
> 
> see snippet below...
> 
> 
> > +
> > +KUnit
> > +=====
> > +
> > +KUnit tests run self-contained logic in the kernel without any CXL topology.
> > +KUnit is suited to logic that can be exercised with controlled test inputs,
> > +including encode/decode helpers, address translation and interleave calculations,
> > +parsers of device- or firmware-supplied data, and mailbox command handling
> > +through a stub transport.
> > +
> > +To run all of the CXL KUnit tests, from the top of the kernel tree::
> > +
> > +  ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/cxl
> > +
> > +This builds a test kernel in .kunit/ using drivers/cxl/.kunitconfig and runs it
> > +under User Mode Linux (UML). The running kernel is not modified, and no
> > +installation is required. The test kernel runs the tests, reports the results,
> > +and exits.
> > +
> > +Add --arch=x86_64 to run the tests under QEMU instead.
> > +
> > +Running during development
> > +--------------------------
> > +
> > +kunit.py builds in .kunit/, but kbuild does not allow an out-of-tree build when
> > +the source tree already contains an in-tree build. If you build the kernel
> > +in-tree, use a separate worktree for KUnit. The worktree contains the committed
> > +sources at the selected revision::
> > +
> > +  git worktree add ../linux-kunit HEAD
> > +  cd ../linux-kunit
> > +  ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/cxl
> > +
> > +To run a single suite, name it::
> > +
> > +  ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/cxl cxl_core_mbox
> > +
> > +Enable KASAN when testing memory safety error paths. It can detect an out-of-bounds
> > +access even when the resulting value does not cause a test assertion to fail::
> > +
> > +  ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/cxl \
> > +      --arch=x86_64 --kconfig_add CONFIG_KASAN=y
> > +  
> 
> Here's what I think (so far) folks need to know about maintenance-
> 
> Maintaining KUnit tests
> =======================
> 
> Use loop bounds and table sizes from the code under test, such as
> ARRAY_SIZE() of a lookup table, so tests adapt as the code evolves.
> Derive expected results from the specification, not the implementation,
> so tests can detect unintended behavior changes.
> 
> When a patch changes behavior covered by a test, update the test in the
> same patch. For example, add newly supported encodings to a valid-value
> table or adjust the expected errno for a new return code.
> 
> A failing test may indicate a regression or a test that needs updating.
> Run the CXL KUnit tests throughout development, not just before posting,
> to catch either case while making changes.
> 

Makes sense to me. With that added
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>