On Tue, 30 Jan 2024 19:41:10 +0100 Paolo Abeni wrote:
Yes, it's VM inside a VM without nested virtualization support. A weird setup, granted, but when we move to bare metal I'd like to enable KASAN, which will probably cause a similar slowdown..
You could possibly get a similar slowdown by disabling HW virt / KVM?
Thanks, the above helped - that is, I can reproduce the failure running the self-tests in a VM with KVM disabled in the host. Funnily enough I can't use plain virtme for that - the virtme VM crashes on boot, possibly due to the wrong 'machine' argument passed to qemu.
FWIW I think you can fix this by passing -o " -cpu Haswell" to vng. Yet another piece of knowledge I wish I didn't have and which I should probably put somewhere public :(
In any case I can't see a sane way to cope with such slow environments except skipping the sensitive cases.
FWIW far the 4 types of issues we've seen were:
- config missing
- OS doesn't ifup by default
- OS tools are old / buggy
- VM-in-VM is just too slow.
There's a bunch of failures in forwarding which look like perf issues. I wonder if we should introduce something in the settings file to let tests know that they are running in very slow env?
I was wondering about passing such info to the test e.g. via an env variable:
vng --run . --user root -- HOST_IS_DAMN_SLOW=true ./tools/testing/selftests/kselftest_install/run_kselftest.sh -t
<whatever>
In any case some tests should be updated to skip the relevant cases accordingly, right?
Which reminds me I need to send the meeting notes from the netdev call :) We went with KSFT_MACHINE_SLOW=yes for now, the NIPA machines should have it set now.