From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWg0c-0006HA-LG for qemu-devel@nongnu.org; Thu, 17 Oct 2013 01:20:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWg0U-00078z-15 for qemu-devel@nongnu.org; Thu, 17 Oct 2013 01:20:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWg0T-00078v-P1 for qemu-devel@nongnu.org; Thu, 17 Oct 2013 01:20:21 -0400 Date: Thu, 17 Oct 2013 08:22:45 +0300 From: "Michael S. Tsirkin" Message-ID: <20131017052245.GB12141@redhat.com> References: <87txgimrd6.fsf@codemonkey.ws> <20131015201706.GB9579@redhat.com> <20131016181800.GB7100@redhat.com> <20131016183732.GA8157@redhat.com> <525F0473.6060408@redhat.com> <20131016220301.GA10908@redhat.com> <525F125C.80403@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Anthony Liguori Cc: Peter Maydell , Gleb Natapov , marcel.a@redhat.com, qemu-devel , Gerd Hoffmann , Igor Mammedov , Paolo Bonzini On Wed, Oct 16, 2013 at 04:52:35PM -0700, Anthony Liguori wrote: > On Wed, Oct 16, 2013 at 3:25 PM, Paolo Bonzini wrote: > > 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. > > I think we could reasonably attempt to validate ACPI tables across > machine versions. > > Since this is qtest, we can even do things like use iasl to > disassemble the blobs on the host. This could be pretty handy for > detecting compatibility issues across machine versions. > > Regards, > > Anthony Liguori Sounds nifty - comparing dis-assembled output is exactly how I tested this manually. This solves the problem that ACPI allows many ways to encode identical tables. > > > > Paolo