On 28/12/20 23:25, Sean Christopherson wrote:
On Wed, Dec 23, 2020, Paolo Bonzini wrote:
This short series adds a generic stress test to KVM unit tests that runs a
series of
Unintentional cliffhanger?
... event injections, timer cycles, memory updates and TLB invalidations.
The configuration of the test is set individually for each VCPU on
the command line, for example:
./x86/run x86/chaos.flat -smp 2 \
-append 'invtlb=1,mem=12,hz=100 hz=250,edu=1,edu_hz=53,hlt' -device edu
runs a continuous INVLPG+write test on 1<<12 pages on CPU 0, interrupted
by a 100 Hz timer tick; and keeps CPU 1 mostly idle except for 250 timer
ticks and 53 edu device interrupts per second.
Maybe take the target cpu as part of the command line instead of implicitly
defining it via group position?
Sure, the command line syntax can be adjusted.
The "duplicate" hz=??? is confusing. E.g.
./x86/run x86/chaos.flat -smp 2 \
-append 'cpu=0,invtlb=1,mem=12,hz=100 cpu=1,hz=250,edu=1,edu_hz=53,hlt' -device edu
For now, the test runs for an infinite time so it's not included in
unittests.cfg. Do you think this is worth including in kvm-unit-tests,
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.
Paolo