All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/4] add "make check"
Date: Tue, 25 Oct 2011 16:16:42 +0200	[thread overview]
Message-ID: <4EA6C4CA.6060301@redhat.com> (raw)
In-Reply-To: <4EA6B947.5030005@redhat.com>

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	other threads:[~2011-10-25 14:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01 15:42 [Qemu-devel] [PATCH 0/4] add "make check" Gerd Hoffmann
2011-09-01 15:42 ` [Qemu-devel] [PATCH 1/4] Probe for libcheck by default Gerd Hoffmann
2011-09-01 19:37   ` Anthony Liguori
2011-09-02  7:42     ` Gerd Hoffmann
2011-09-05  7:39       ` Markus Armbruster
2011-09-01 15:42 ` [Qemu-devel] [PATCH 2/4] move checks to separate variable Gerd Hoffmann
2011-09-01 15:42 ` [Qemu-devel] [PATCH 3/4] add "make check" target Gerd Hoffmann
2011-09-01 15:42 ` [Qemu-devel] [PATCH 4/4] add test-coroutine to checks Gerd Hoffmann
2011-09-05  7:55 ` [Qemu-devel] [PATCH 0/4] add "make check" Markus Armbruster
2011-10-24 18:43   ` Eduardo Habkost
2011-10-24 18:57     ` Anthony Liguori
2011-10-25 12:21       ` Kevin Wolf
2011-10-25 13:27         ` Gerd Hoffmann
2011-10-25 14:16           ` Kevin Wolf [this message]
2011-10-25 15:03           ` Eduardo Habkost
2011-10-25 15:22             ` Kevin Wolf
2011-10-26 20:49               ` Anthony Liguori
2011-10-27  8:20                 ` Kevin Wolf
2011-10-27 17:58                   ` Anthony Liguori
2011-10-27 21:22                     ` Michael Roth
2011-10-25 15:54             ` Gerd Hoffmann
2011-10-25 16:30             ` Lucas Meneghel Rodrigues
2011-10-25 15:03         ` Anthony Liguori
2011-11-01 18:03 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA6C4CA.6060301@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.