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