Re: [PATCH kvm-unit-tests 0/4] API test framework

[Avi Kivity <avi@redhat.com>]

On 11/29/2010 06:09 PM, Marcelo Tosatti wrote:
> I fail to see practical advantages of this compared to current unit
> tests. Could you give some exciting examples?

You can test the API directly, or set up specific states that are hard 
to reach from a guest.

Examples:
- test mst's dirty log fix by writing repeatedly from a vcpu while 
polling the dirty log from another thread (plan to do this for v2)
- set up wierd states (nmi-blocked-by-sti), force an exit (using pio or 
debug registers), verify state save shows the expected values

> The fact that it does not run inside QEMU
> means you can't test QEMU interactions (re:
> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/59060).

Using qemu means restricting outselves to the subset of kvm that qemu 
uses.  Since it's a very large subset, it's not a problem, but still.  
Also, it's hard to test corner cases with qemu, see the examples above.

> Perhaps you can write a save/restore example as mentioned in the URL
> above?

Should be easy, will try for v2 or v3.

> To me it seems having an interface to QEMU from unit tests would be more
> beneficial.

It's still very roundabout compared to:

- set up mce handler (can do it in host code)
- issue ioctl
- run()
- see whether the handler was invoked or not.


-- 
error compiling committee.c: too many arguments to function