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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 17, 2013 at 12:25:32AM +0200, 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.

Well all of them use the test device to report status, right?
Do they work on e.g. kvmtool?
If anyone uses these tests outside QEMU then maybe it's
worth it to be nice and keep it separate.
If not it's just extra pain and compatibility worries without
any real gain - and if someone starts using it
this way down the line we'll be able to use something
like git subtree to extract it again.

For example I think it might be nice to switch everyone
to use pci device instead of fixed ports - less magic
numbers this way. But if I need to keep it working on
old qemu and keep two versions of code around, I'd
probably not bother.

> >> 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