From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJAQ4-0005dZ-Py for qemu-devel@nongnu.org; Wed, 26 Oct 2011 16:49:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJAQ3-0007Fv-8Q for qemu-devel@nongnu.org; Wed, 26 Oct 2011 16:49:52 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:38112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJAQ2-0007Fl-VL for qemu-devel@nongnu.org; Wed, 26 Oct 2011 16:49:51 -0400 Received: by gyg10 with SMTP id 10so2325866gyg.4 for ; Wed, 26 Oct 2011 13:49:50 -0700 (PDT) Message-ID: <4EA8726A.20309@codemonkey.ws> Date: Wed, 26 Oct 2011 15:49:46 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1314891739-1881-1-git-send-email-kraxel@redhat.com> <20111024184320.GA29718@otherpad.lan.raisama.net> <4EA5B51F.8040502@codemonkey.ws> <4EA6A9CD.5080103@redhat.com> <4EA6B947.5030005@redhat.com> <20111025150302.GC29718@otherpad.lan.raisama.net> <4EA6D436.6030703@redhat.com> In-Reply-To: <4EA6D436.6030703@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] add "make check" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Lucas Meneghel Rodrigues , qemu-devel@nongnu.org, Markus Armbruster , Gerd Hoffmann , Cleber Rosa , Avi Kivity On 10/25/2011 10:22 AM, Kevin Wolf wrote: > Am 25.10.2011 17:03, schrieb Eduardo Habkost: > I think qemu-iotests could be considered an instance of B) > >> C) Functional tests that just need to run a small binary with no OS >> installed in the guest, but running a fully-feature qemu process. >> - The tests in the 'tests' directory do this, right? kvm-unittests >> does this, right? > > Not sure what test/ does, but for kvm-unittests yes. And this is also > what I was talking about. Thinking more about this... We could add a new '-x-test-server CHR' option. When this option is added, it would do the following: 1) Open CHR character device 2) Use /dev/shm for guest memory 3) Listen for connections on CHR 4) When something connects to CHR a) reset device model b) send /dev/shm fd over CHR c) register CPU physical memory client 1. upon CPU physical memory changes, send the change info over CHR d) instead of doing [kvm_]cpu_exec(), block reading on CHR So when you launch qemu with -x-test-server, it'll sit there doing nothing terribly useful. But this lets you write a program that connects to CHR, and then by mapping {out,in}[bwl] to RPCs over the connection, and accessing RAM via mmap()'ing the passed fd using the client mapping table, you can essentially write kvm-unittest style tests while still having full access to libc. And since each test program can reset QEMU after running, you could very nicely tie into something like gtest as a unit test framework. I think it's pretty appealing from a debugability perspective too. It also means that it's possible to have 100% C test cases such that you could still build something like ppc64-softmmu and run it against the written test cases without having to really understand ppc64 assembly or have a ppc64 build environment (to generate native binaries to run under ppc64 TCG). I think this could work out fairly well as a unit test framework. Regards, Anthony Liguori > >> D) Functional tests that need a minimal OS installed, with, e.g., at >> least a Linux kernel and a shell. >> - This is what Gerd's patch below does, right? Also, KVM-Autotest can >> be used for this. >> E) Functional tests that need a full OS installed and configured. >> - Today we use KVM-Autotest for this. >> >> >> Does the above model look correct/complete, or is there some case I >> missed? > > I think it covers what we need. > > Kevin >