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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
