On Fri, May 30, 2025 at 09:50:22AM -0700, David Matlack wrote:
> On Mon, May 26, 2025 at 10:15 AM Jason Gunthorpe <j...@nvidia.com> wrote:
> >
> > On Fri, May 23, 2025 at 11:29:52PM +0000, David Matlack wrote:
> > > From: Josh Hilke <jrhi...@google.com>
> > >
> > > Add a command line arg to vfio_dma_mapping_test to choose the size of
> > > page which is mapped in VFIO.
> >
> > This doesn't seem right..
> >
> > Tests should run automously, test all possible sizes using a fixture.
>
> This test uses a fixture already. I assume you're referring to
> FIXTURE_VARIANT()?
Yes
> I'll explore doing this. For a single dimension this looks possible.
> But for multiple dimensions (e.g. cross product of iommu_mode and
> backing_src) I don't see a clear way to do it. But that's just after a
> cursory look.
Explicitly list all the combinations with macros?
Enhance the userspace tests allow code to generate the
variants? Kernel tests can do this:
/**
* KUNIT_CASE_PARAM - A helper for creation a parameterized &struct kunit_case
*
* @test_name: a reference to a test case function.
* @gen_params: a reference to a parameter generator function.
*
* The generator function::
*
* const void* gen_params(const void *prev, char *desc)
*
* is used to lazily generate a series of arbitrarily typed values that fit into
* a void*. The argument @prev is the previously returned value, which should be
* used to derive the next value; @prev is set to NULL on the initial generator
* call. When no more values are available, the generator must return NULL.
* Optionally write a string into @desc (size of KUNIT_PARAM_DESC_SIZE)
* describing the parameter.
*/
#define KUNIT_CASE_PARAM(test_name, gen_params) \
{ .run_case = test_name, .name = #test_name, \
.generate_params = gen_params, .module_name = KBUILD_MODNAME}
> For context, the pattern of passing in test configuration via flags
> rather than automatically testing all combinations is something
> inherited from KVM selftests. That's the common pattern there. There's
> some work happening there to encode configurations at a higher level
> using testcase files and a runner [1].
IMHO it is not good, it should be done with fixtures and variants
slicing the test by matching the test fixture/name/etc.
It doesn't really make sense to have a C test runner that you have to
invoke from bash just because the C stuff is not very good..
> - The library needs to know which device to use. In this RFC that
> works by the user passing in BDF as a positional argument to each
> test.
I'd probably say it should scan the available vfio devices and pick
the first that it understands how to use. Command line would be an
option.
> - For tests that use HugeTLB (like this one), the test requires the
> user to have already allocated HugeTLB memory for it to use.
Other tests do this already, like the iommufd test assumes it can get
hugetlb mmaps. Skip the tests on allocation failure is the best I
think you can do.
It would be nice to have test metadata so a runner frame work could
know to provide this stuff in the environment.
Jason
