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

[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.

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