From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCZCQ-0000xW-9P for qemu-devel@nongnu.org; Mon, 04 Mar 2013 12:29:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCZCI-00074W-DK for qemu-devel@nongnu.org; Mon, 04 Mar 2013 12:29:18 -0500 Received: from mail-ob0-x22c.google.com ([2607:f8b0:4003:c01::22c]:53601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCZCI-00073z-1E for qemu-devel@nongnu.org; Mon, 04 Mar 2013 12:29:10 -0500 Received: by mail-ob0-f172.google.com with SMTP id tb18so2061116obb.31 for ; Mon, 04 Mar 2013 09:29:08 -0800 (PST) Sender: fluxion Date: Mon, 4 Mar 2013 11:26:28 -0600 From: mdroth Message-ID: <20130304172628.GB21850@vm> References: <5134CA4A.7040700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5134CA4A.7040700@redhat.com> Subject: Re: [Qemu-devel] The state of testing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Kevin Wolf , Anthony Liguori , Juan Quintela , Stefan Hajnoczi , qemu-devel , Markus Armbruster , Amit Shah 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 >