qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] add "make check"


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] add "make check"
Date: Thu, 27 Oct 2011 12:58:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]