From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJUDv-00005z-AF for qemu-devel@nongnu.org; Thu, 27 Oct 2011 13:58:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJUDt-0004CK-Vd for qemu-devel@nongnu.org; Thu, 27 Oct 2011 13:58:39 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:44810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJUDt-0004CC-Ro for qemu-devel@nongnu.org; Thu, 27 Oct 2011 13:58:37 -0400 Received: by ywb3 with SMTP id 3so3459107ywb.4 for ; Thu, 27 Oct 2011 10:58:37 -0700 (PDT) Message-ID: <4EA99BC8.9040402@codemonkey.ws> Date: Thu, 27 Oct 2011 12:58:32 -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> <4EA8726A.20309@codemonkey.ws> <4EA91460.9050301@redhat.com> In-Reply-To: <4EA91460.9050301@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 , Avi Kivity , Cleber Rosa , Gerd Hoffmann On 10/27/2011 03:20 AM, Kevin Wolf wrote: > Am 26.10.2011 22:49, schrieb Anthony Liguori: >> 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. > > IRQs need to go through the connection as well. Yes, forgot to mention that. > > Oh, and you would finally have a C user for libqmp. The test cases > definitely need to be able to access the monitor. For example I would > really love to have test cases for the I/O error paths that stop the VM > (or actually it's the resume that must be tested). Yeah, tunnelling a monitor session sounds like a really good idea. >> 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. > > Sounds great, where are the patches? ;-) Heh, need to find a volunteer although I spent a few minutes this afternoon trying to figure out how hard it would be. Turns out, it's much simpler than I expected if you do the same trick that Xen does. Instead of mucking with hooking cpu_exec, Xen simply starts the CPUs in the halted state such that TCG simply never runs. The following patch is all we really need. test_init() just needs to register the appropriate file descriptor callbacks and then in the data path dispatch PIO/MMIO. It would also need to override cpu_interrupt_handler to intercept interrupt operations. diff --git a/hw/pc.c b/hw/pc.c index eb4c2d8..f3fd32d 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -923,12 +923,18 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int level) } } +extern int test_allowed; + static void pc_cpu_reset(void *opaque) { CPUState *env = opaque; cpu_reset(env); - env->halted = !cpu_is_bsp(env); + if (test_allowed) { + env->halted = 1; + } else { + env->halted = !cpu_is_bsp(env); + } } static CPUState *pc_new_cpu(const char *cpu_model) diff --git a/vl.c b/vl.c index 1ddb17b..adc626a 100644 --- a/vl.c +++ b/vl.c @@ -1988,6 +1988,19 @@ static int tcg_init(void) return 0; } +static int test_init(void) +{ + printf("Hello World\n"); + return 0; +} + +static int test_available(void) +{ + return 1; +} + +int test_allowed = 1; + static struct { const char *opt_name; const char *name; @@ -1998,6 +2011,7 @@ static struct { { "tcg", "tcg", tcg_available, tcg_init, &tcg_allowed }, { "xen", "Xen", xen_available, xen_init, &xen_allowed }, { "kvm", "KVM", kvm_available, kvm_init, &kvm_allowed }, + { "test", "Test", test_available, test_init, &test_allowed }, }; static int configure_accelerator(void) > Kevin >