On 12/01/21 23:28, Sean Christopherson wrote:
What's the motivation for this type of test? What class of bugs can it find
that won't be found by existing kvm-unit-tests or simple boot tests?
Mostly live migration tests. For example, Maxim found a corner case in
KVM_GET_VCPU_EVENTS that affects both nVMX and nSVM live migration (patches
coming), and it is quite hard to turn it into a selftest because it requires
the ioctl to be invoked exactly when nested_run_pending==1. Such a test
would allow stress-testing live migration without having to set up L1 and L2
virtual machine images.
Ah, so you run the stress test in L1 and then migrate L1?
Yes. I can't exclude that it would find bugs without migration, but I
hope we'd have stomped them by now.
What's the biggest hurdle for doing this completely within the unit test
framework? Is teaching the framework to migrate a unit test the biggest pain?
Yes, pretty much. The shell script framework would show its limits.
That said, I've always treated run_tests.sh as a utility more than an
integral part of kvm-unit-tests. There's nothing that prevents a more
capable framework from parsing unittests.cfg.
Paolo
