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 16:16:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

Am 25.10.2011 15:27, schrieb Gerd Hoffmann:
>   Hi,
> 
>>> I was hoping for more, but maybe we just need to start here and grow 
>>> organically, I'll queue it again.
>>
>> 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 ...

Which is more or less the only way to do a reasonably complete test
(particularly including the error handling paths that a current Linux
might never exercise) at least for the host controllers.

I'm not sure if you can send arbitrary USB packets from Linux (is USB
passthrough really direct passthrough or does the kernel mess with it?),
so maybe for everything above host controllers you could use that. If
you can't, you're back to your own USB stack.

Kevin



reply via email to

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