qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PULL 42/43] piix4: add acpi pci hotplug support
Date: Thu, 17 Oct 2013 08:22:45 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]