Andrew Jones <drjones@xxxxxxxxxx> writes: > On Wed, Dec 01, 2021 at 04:20:02PM +0000, Alex Bennée wrote: >> >> Andrew Jones <drjones@xxxxxxxxxx> writes: >> >> > On Thu, Nov 18, 2021 at 06:46:44PM +0000, Alex Bennée wrote: >> >> The upcoming MTTCG tests don't need to be run for normal KVM unit >> >> tests so lets add the facility to have a custom set of tests. >> > >> > I think an environment variable override would be better than this command >> > line override, because then we could also get mkstandalone to work with >> > the new unittests.cfg files. Or, it may be better to just add them to >> > the main unittests.cfg with lines like these >> > >> > groups = nodefault mttcg >> > accel = tcg >> > >> > That'll "dirty" the logs with SKIP ... (test marked as manual run only) >> > for each one, but at least we won't easily forget about running them from >> > time to time. >> >> So what is the meaning of accel here? Is it: >> >> - this test only runs on accel FOO >> >> or >> >> - this test defaults to running on accel FOO >> >> because while the tests are for TCG I want to run them on KVM (so I can >> validate the test on real HW). If I have accel=tcg then: >> >> env ACCEL=kvm QEMU=$HOME/lsrc/qemu.git/builds/all/qemu-system-aarch64 ./run_tests.sh -g mttcg >> SKIP tlbflush-code::all_other (tcg only, but ACCEL=kvm) >> SKIP tlbflush-code::page_other (tcg only, but ACCEL=kvm) >> SKIP tlbflush-code::all_self (tcg only, but ACCEL=kvm) >> ... >> >> so I can either drop the accel line and rely on nodefault to ensure it >> doesn't run normally or make the env ACCEL processing less anal about >> preventing me running TCG tests under KVM. What do you think? > > Just drop the 'accel = tcg' line. I only suggested it because I didn't > know you also wanted to run the MTTCG "specific" tests under KVM. Now, > that I do, I wonder why we wouldn't run them all the time, i.e. no > nodefault group? Do the tests not exercise enough hypervisor code to > be worth the energy used to run them? I think in most cases if they fail under KVM it wouldn't be due to the hypervisor being broken but the silicon not meeting it's architectural specification. I'm fine with them being nodefault for that. I'm not sure how much the tlbflush code exercises on the host. There is a WIP tlbflush-data which might make a case for being run more regularly on KVM. > > Thanks, > drew -- Alex Bennée
