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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/4] add "make check"
Date: Tue, 25 Oct 2011 17:22:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

Am 25.10.2011 17:03, schrieb Eduardo Habkost:
> On Tue, Oct 25, 2011 at 03:27:35PM +0200, Gerd Hoffmann wrote:
> [...]
>>> A while ago I played with some simple IDE tests. It basically was a
>>> small x86 kernel with an empty image that sends IDE commands and prints
>>> some results, and a script that invokes the guest and checks whether the
>>> test has passed or failed.
>>
>> That reminds me that I've started toying with running tests inside a
>> guest too.  Stopped working on it a while back due to other priorities.
>>  Attached what I have so far.
>>
>>> So at first I started with my own multiboot kernel and copied over some
>>> parts of kvm-unittest's libc. Clearly not the best idea once it's more
>>> than a couple of lines, so at some point I took the code and integrated
>>> with my real kvm-unittests repository.
>>>
>>> Now I don't have to duplicate code any more, but at the same time
>>> there's no chance that a 'make check' in an upstream qemu tree could run
>>> this. Tests for other devices will have exactly the same problem.
>>>
>>> Any suggestions on how to go forward with this kind of tests? Should
>>> this go into qemu or into kvm-unittests? Or should kvm-unittests be
>>> merged into the qemu tree? Or is the approach completely wrong?
>>
>> I think we should have some framework to run tests inside the guest in
>> the qemu source tree.  I'm not sure kvm-unittests is the right tool for
>> the job though.  It is quite low-level and mainly targets the kvm bits
>> inside the linux kernel.  Testing -- for example -- usb device emulation
>> would pretty much require writing a usb stack for kvm-unitests ...
> 
> We have a framework to run tests inside a fully-installed guest, that's
> KVM-Autotest. But maybe it's too much for the kind of tests you need, I
> don't know. There are different "levels" of testing, with different
> reequirements, and we need to have good tools for all levels.

Autotest works for an entirely different use case.

Autotest is the right tool when you can let the tests run over night or
over the weekend. Good to run regularly on the current git tree, the
right thing to do to test release candidates.

It's the wrong tool for testing the patch that I'm currently working on.
The focus here is on being able to run very quick tests. I don't want to
wait for a guest installation to complete, and I don't even necessarily
want to wait for a full-blown Linux guest to boot up.

> Just trying to enumerate the kind of tests somebody may need:
> 
> A) Simple unit tests for internal qemu C functions
>    - 'make check' can run them, using either libcheck or gtest.
> B) Functional tests that tests actual virtualization/emulation, but only
>    of some specific subsystems, not using a fully-featured qemu process.
>    - We don't have anything like that, today, right? I am not sure we
>      need it.

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.

> 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



reply via email to

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