From: mdroth <mdroth@linux.vnet.ibm.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Juan Quintela <quintela@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Amit Shah <amit.shah@redhat.com>
Subject: Re: [Qemu-devel] The state of testing
Date: Mon, 4 Mar 2013 11:26:28 -0600 [thread overview]
Message-ID: <20130304172628.GB21850@vm> (raw)
In-Reply-To: <5134CA4A.7040700@redhat.com>
On Mon, Mar 04, 2013 at 05:22:34PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > How are things looking with device emulation, migration, monitor, char, etc?
>
> At the moment autotest/virt-test is pretty much the only workable thing
> for non-trivial devices because libqtest lacks infrastructure for pci
> and anything building on top of pci.
>
> usb has no in-tree tests, but has autotest coverage.
>
> chardevs have some autotest coverage, /me wrote a test for
> chardev-{add,remove} qmp commands. Still need to rebase + polish +
> submit that one though.
>
> Migration coverage is pretty bad overall I think.
I've been working on a tool to try to do build-bot-like coverage for
cross-version migration. It's basically a fork of Anthony's qemu-test
suite that uses the same qemu-jeos/initrd system and a single test
harness with pre-migration/post-migration/post-migration reboots tests
case.
The plan is to get it in-tree along with qemu-test, with a wrapper
that'll test current->current migration as part of `make check`, and set up
a test bot with older qemu builds to test cross-version compatibility and
generate a report along these lines:
http://wiki.qemu.org/Migration/Compatibility
I can throw the code up somewhere if anyone is interested, but it's
mostly for internal testing atm.
> What is the state of the idl patch series btw?
The IDL to generate serialization routines for device state is fairly
well-fleshed out, but there was a lot of flux in the code-parser to
process them in later stages of getting the initial code upstreamed, so
I wanted to hold off a bit to refactor the parser and consider some
alternatives (namely, Peter's suggestion of generating device structs
from a higher-level IDL, or leveraging other tools to generate the ASTs)
I should have some cycles to work on it more after the 1.4.1 release.
>
> cheers,
> Gerd
>
next prev parent reply other threads:[~2013-03-04 17:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 15:53 [Qemu-devel] The state of testing Stefan Hajnoczi
2013-03-04 16:22 ` Gerd Hoffmann
2013-03-04 17:26 ` mdroth [this message]
2013-03-05 9:46 ` Kevin Wolf
2013-03-05 10:46 ` Stefan Hajnoczi
2013-03-05 11:17 ` Gerd Hoffmann
2013-03-05 15:59 ` Lucas Meneghel Rodrigues
2013-03-05 16:14 ` Gerd Hoffmann
2013-03-05 16:21 ` Lucas Meneghel Rodrigues
2013-03-06 9:53 ` Stefan Hajnoczi
2013-03-06 12:00 ` Markus Armbruster
2013-03-05 16:09 ` Lucas Meneghel Rodrigues
2013-03-05 16:23 ` Gerd Hoffmann
2013-03-05 16:41 ` Lucas Meneghel Rodrigues
2013-03-04 19:20 ` Anthony Liguori
2013-03-05 10:45 ` Stefan Hajnoczi
2013-03-05 10:11 ` Amit Shah
2013-03-05 15:54 ` Lucas Meneghel Rodrigues
2013-03-11 8:52 ` Amit Shah
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=20130304172628.GB21850@vm \
--to=mdroth@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=amit.shah@redhat.com \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).