From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJk9-0001GG-Cc for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:26:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgJk8-0002k4-CY for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:26:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgJk8-0002k0-3M for qemu-devel@nongnu.org; Thu, 29 Dec 2011 12:26:16 -0500 Message-ID: <4EFCA2AF.5000806@redhat.com> Date: Thu, 29 Dec 2011 19:26:07 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EEF70B4.3070109@us.ibm.com> <4EF73EF5.8050606@redhat.com> <4EF88EC0.8020301@codemonkey.ws> <4EF8FC88.70809@redhat.com> <4EFA4829.4000207@redhat.com> <4EFA80EA.3050405@codemonkey.ws> <4EFAA2A2.4000107@redhat.com> <4EFB2764.7040006@codemonkey.ws> <4EFB2F36.2090408@redhat.com> <4EFB35AB.6040003@redhat.com> <4EFB4757.4020504@codemonkey.ws> <4EFB5138.5020502@redhat.com> <4EFC916E.4070902@codemonkey.ws> <4EFC9706.4090500@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "lmr@redhat.com" , Stefan Hajnoczi , cleber@redhat.com, dlaor@redhat.com, qemu-devel , Gerd Hoffmann , Cleber Rosa On 12/29/2011 07:22 PM, Peter Maydell wrote: > On 29 December 2011 16:36, Avi Kivity wrote: > > Yes; but using Linux limits you to what it exposes (of course Linux > > exposes quite a lot, so that's mostly a non issue; but we'll have > > counterexamples). > > Actually IME Linux is pretty conservative about how it uses devices. > A lot of the ARM device models have gaping holes in their emulation > which we've never needed to fix because Linux simply doesn't use > those features (eg the PL080 DMA controller which doesn't actually > implement DMA!) We were discussing fingerprinting, not actually driving the device. For that, I think we're all agreed that qtest is vastly superior to using an OS driver. > I think for devices what would be particularly useful would be > if you can write a (simple) test for something at the register > level, which generates an image which you can run on the real > hardware as well as on QEMU. Then you can confirm that your test > case is correct. Otherwise the tests are just going to bake in the > same assumptions/misconceptions about what the hardware does as > the QEMU model. That is exactly qtest. > My guess is that a serious attempt at tests covering all the > functionality of a device is probably approximately doubling > the effort required for a device model, incidentally. A > half-hearted attempt probably doesn't buy you much over > automating "boot the guest OS and prod its driver". Agreed. -- error compiling committee.c: too many arguments to function