On Wed, Oct 16, 2013 at 04:52:35PM -0700, Anthony Liguori wrote: > On Wed, Oct 16, 2013 at 3:25 PM, Paolo Bonzini <pbonz...@redhat.com> 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
