From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWZXF-0001hI-L7 for qemu-devel@nongnu.org; Wed, 16 Oct 2013 18:25:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWZX7-0000Do-69 for qemu-devel@nongnu.org; Wed, 16 Oct 2013 18:25:45 -0400 Received: from mail-ee0-x22c.google.com ([2a00:1450:4013:c00::22c]:56532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWZX6-0000Dc-St for qemu-devel@nongnu.org; Wed, 16 Oct 2013 18:25:37 -0400 Received: by mail-ee0-f44.google.com with SMTP id b47so682669eek.3 for ; Wed, 16 Oct 2013 15:25:36 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <525F125C.80403@redhat.com> Date: Thu, 17 Oct 2013 00:25:32 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <525D51C3.2050201@redhat.com> <20131015143530.GA7763@redhat.com> <525D5630.1030801@redhat.com> <87txgimrd6.fsf@codemonkey.ws> <20131015201706.GB9579@redhat.com> <20131016181800.GB7100@redhat.com> <20131016183732.GA8157@redhat.com> <525F0473.6060408@redhat.com> <20131016220301.GA10908@redhat.com> In-Reply-To: <20131016220301.GA10908@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Peter Maydell , gleb@redhat.com, marcel.a@redhat.com, qemu-devel , Gerd Hoffmann , Anthony Liguori , Igor Mammedov Il 17/10/2013 00:03, Michael S. Tsirkin ha scritto: > On Wed, Oct 16, 2013 at 11:26:11PM +0200, Paolo Bonzini wrote: >> Il 16/10/2013 20:37, Michael S. Tsirkin ha scritto: >>> Gleb, Paolo, what do you think? OK to merge kvm unit test >>> into qemu? It depends on qemu anyway, in-tree will make it easier. >>> Maybe someone's looking at this already? >> >> I think merging KVM unit tests doesn't make much sense because, with >> some small exceptions, it is mostly a test or a benchmark for KVM. > > But why keep them separate? They need qemu to work, don't they? Not necessarily. They need a userspace component of course, but most of them do not need something as big as QEMU. Most tests, perhaps all, only write to a handful of ports and use no BIOS services. >> What >> may make sense is to have a quick way to run autotest on a QEMU tree, >> with a subset of testcases that doesn't take too much time (let's say <4 >> hours) > > That's not really reasonable for make check though. Why not? When I was working on GCC I usually ran a subset of the testsuite manually and then did a full run overnight. I said <4 hours because it lets you do 2 runs (baseline and patched) while you sleep. However I agree it's more than we're used to, so I'd not put it under "make check". Still, having it available from make would be nice. >> and is more or less guaranteed to pass. > > That's still the main challenge. Yep. :( >> qtest could at best host some sanity checks on the ACPI tables, which >> would catch the MCFG problems that Gerd reported on v5. > > Depends on how deep the test understands ACPI - the signature > was wrong I think. > > Note I was testing this too - comparing tables between > revisions. I just didn't notice that list of tables > to test included was generated by me on piix, so > MCFG wasn't tested. So we could have a qtest for sanity checking ACPI tables. At least fw_cfg is one of the few components that has qtest infrastructure... I don't think we need to do more than that though. The set of sanity checks can start with a simple list of tables that "have to be there" for a given machine type. Paolo