[Top][All Lists]
[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: |
Thu, 27 Oct 2011 10:20:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
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.
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).
> 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? ;-)
Kevin
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Eduardo Habkost, 2011/10/24
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Anthony Liguori, 2011/10/24
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Kevin Wolf, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Gerd Hoffmann, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Kevin Wolf, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Eduardo Habkost, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Kevin Wolf, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Anthony Liguori, 2011/10/26
- Re: [Qemu-devel] [PATCH 0/4] add "make check",
Kevin Wolf <=
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Anthony Liguori, 2011/10/27
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Michael Roth, 2011/10/27
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Gerd Hoffmann, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Lucas Meneghel Rodrigues, 2011/10/25
- Re: [Qemu-devel] [PATCH 0/4] add "make check", Anthony Liguori, 2011/10/25