Re: [PATCH v4 1/9] KVM: selftest: Create KVM selftest runner
Sean Christopherson <[email protected]>
| Newsgroups | org.infradead.lists.kvm-riscv,dev.linux.lists.kvmarm,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
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. -- kvm-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kvm-riscv