Re: [PATCH v4 1/9] KVM: selftest: Create KVM selftest runner
Ackerley Tng <[email protected]>
| Newsgroups | org.infradead.lists.kvm-riscv,dev.linux.lists.kvmarm,org.kernel.vger.kvm |
|---|---|
| Message-ID | <CAEvNRgFLnGkqvvks3joAwPjqLz=ATmqiS0UWk71g+YEsxNsfsg@mail.gmail.com> |
Sean Christopherson <[email protected]> writes: > On Thu, Jun 11, 2026, Ackerley Tng wrote: >> Sean Christopherson <[email protected]> writes: >> >> > On Wed, Jun 10, 2026, Ackerley Tng wrote: >> >> Vipin Sharma <[email protected]> writes: >> >> My (future) use case is that with hugepages, I want to run something >> >> like >> >> >> >> ./guest_memfd_test --order=0 >> >> ./guest_memfd_test --order=9 >> >> ./guest_memfd_test --order=18 >> >> >> >> And 0, 9 and 18 are the supported HugeTLB orders on the machine being >> >> tested. I'd like to iterate over supported HugeTLB orders at runner >> >> runtime instead of at build time. >> > >> > No. The right way to handle this is to define testcases for the "interesting" >> > sizes, and then rely on the test itself to SKIP if the size is unsupported. This >> > is no different than a test that requires EPT, or nested VMX, or nested SVM, etc. >> >> That should work too. So at build time I'd make it define all the >> possible HugeTLB sizes on every arch, and then skip as necessary. > > Not necessarily at "build time", the testcases can also come from your local > environment. > >> Why though, why not find the supported sizes at runtime? > > You can find the supported sizes at runtime, just not in the test runner. I want > the runner itself to be largely oblivious to what's its running. Disallowing > more or less _any_ test specific configuration/setup in the runner is the only > way I see of keeping the runner strictly focused on running tests/testcases. The runner should 100% focus on running tests, I think it's hard for the runner to avoid the process of test discovery though. The current test discovery process is to go down the tree of directories and find files, 1 file == 1 testcase. Each file should (statically) contain a single command. Since you're not opposed to runtime discovery of test cases, how about something like: if the test case file has executable permissions execute it and get back a list of test cases to be run. else read it as a single test case. I'd then use the executable version, check HugeTLB setup on the machine under test and return bunch of separate commands to be run (each with a different HugeTLB size). The runner still doesn't need to deal test-specific config, that's part of the executable that tells the runner what to run. -- kvm-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kvm-riscv