Re: [PATCH 00/12] Introduce new acpi/smbios qtests using biosbits

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

On Tue, Jun 28, 2022 at 11:21:44AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 28, 2022 at 06:16:06AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jun 28, 2022 at 11:06:11AM +0100, Daniel P. Berrangé wrote:
> > > Ok, with that kind of size, it is definitely not something we want to
> > > be committing to git either,
> > 
> > Not to qemu git I think.
> > 
> > > nor consuming via a submodule since the
> > > latter would bloat the release tarballs too.
> > 
> > Hmm - why? We don't have to put the submodule in the tarball if we don't
> > want to. People consuming tarballs probably do not need these tests
> > anyway - just a basic smoketest is all that is needed.
> 
> That feels very dubious. Upstream doesnt test every scenario that users
> build & run in. Especially with Fedora rawhide we've often found problems
> which upstream QEMU missed, particularly where new GCC releases have bugs
> causing subtle mis-compilation of code.
> 
> With regards,
> Daniel

IMHO these tests are not really useful for that.

What they do is verify that our ACPI tables are sane -
in addition to the manual review with disassembler we do currently.

We already have tests that verify that qemu generates expected ACPI
tables and that is enough for what you describe.

A miscompiled qemu will generate acpi tables that differ from expected
ones and the simple bit for bit test will fail.
No need to run acpipica within guest.




> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|