Re: [RFC PATCH kvm-unit-tests 0/4] add generic stress test

[Sean Christopherson <seanjc@google.com>]

On Sat, Jan 02, 2021, Paolo Bonzini wrote:
> 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.

Ah, so you run the stress test in L1 and then migrate L1?

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?
Writing a "unit test" that puts an L2 guest into a busy loop doesn't seem _that_
bad.