From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH kvm-unit-tests 0/4] API test framework Date: Wed, 01 Dec 2010 12:38:50 +0200 Message-ID: <4CF625BA.8060800@redhat.com> References: <1290595933-13122-1-git-send-email-avi@redhat.com> <20101129160915.GA16443@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14808 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752959Ab0LAKiw (ORCPT ); Wed, 1 Dec 2010 05:38:52 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB1AcqrT016109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Dec 2010 05:38:52 -0500 In-Reply-To: <20101129160915.GA16443@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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