Patchwork [0/4] add "make check"

login
register
mail settings
Submitter Anthony Liguori
Date Oct. 27, 2011, 5:58 p.m.
Message ID <4EA99BC8.9040402@codemonkey.ws>
Download mbox | patch
Permalink /patch/122198/
State New
Headers show

Comments

Anthony Liguori - Oct. 27, 2011, 5:58 p.m.
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.



> Kevin
>
Michael Roth - Oct. 27, 2011, 9:22 p.m.
On Thu, 27 Oct 2011 12:58:32 -0500, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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)
> 

vl.c seems to have changed a bit since then, but I think this was the same basic approach we took with QTest:

http://repo.or.cz/w/qemu/mdroth.git/commitdiff/2e55d8a892297512f6c7883aff2c4b082bd6a3d5?hp=07d8a50cb0e096c5cdc5a81b8030e40833664dd3

http://wiki.qemu.org/Features/QTest

There was even a brief period where we were using gtest, but GLib hadn't been merged yet so we pulled it "temporarially" before going off and working on other stuff.

> 
> > Kevin
> >
> 
>

Patch

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)